Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't

[Matthieu . Rioteau]

Hi Bob,

I already did such kind of investigations. ;-)
But did it again (double checking is not too much) very carefully.

First (following your advice), I look at the mirror...snapshot - which is 
the current state.
I took here 2 files for example :
--------------------
File home/USER/.VirtualBox/VirtualBox.xml
  Type reg
  Size 1077
  SHA1Digest 946f1f2da7b56fa6846df8ee33205a2f7757cf9d
  ModTime 1305099285
  Uid 2001
  Uname :
  Gid 2000
  Gname :
  Permissions 384
File home/USER/.VirtualBox/compreg.dat
  Type reg
  Size 1184
  SHA1Digest bc535745ddeccc5edc4e1e6e9079d2330c72dee5
  ModTime 1305099280
  Uid 2001
  Uname :
  Gid 2000
  Gname :
  Permissions 420
--------------------

Then look at the mirror...diff - which was 2 backups ago, the day where 
ridff-backup marked these files as changed :
--------------------
File home/USER/.VirtualBox/VirtualBox.xml
  Type reg
  Size 1077
  SHA1Digest 946f1f2da7b56fa6846df8ee33205a2f7757cf9d
  ModTime 1305099285
  Uid 2001
  Uname USER
  Gid 2000
  Gname :
  Permissions 384
File home/USER/.VirtualBox/compreg.dat
  Type reg
  Size 1184
  SHA1Digest bc535745ddeccc5edc4e1e6e9079d2330c72dee5
  ModTime 1305099280
  Uid 2001
  Uname USER
  Gid 2000
  Gname :
  Permissions 420
--------------------

So I think here is the key. You can see that uname is once void and once 
filled with the user name.
It also appears that "faulty" changes can be of 2 sorts :
 - Uname was void and is now filled
 - Uname was filled and is now void

Now, running a "stat" command on a file where uname is currently void (in 
rdiff mirror) correctly returns the owner name.

A strange thing remains : running a rdiff-backup --compare-at-time 2B (or 
even 3B or 4B) on a folder chere files changed returns "No changes found. 
Directory matches archive data.".
Notice that --compare-hash-at-time or --compare-full-at-time returns the 
same.
So is it possible that documentation tells that --compare-at-time do the 
same as when a backup is runned, but that uname is actually used only for 
true backups and not for --compare option ?

The last weird thing is that if I browse through the "increments/" folder, 
I will find a very small .diff file for each changed file.
Example with the first file listed above :
--------------------
hexdump -C VirtualBox.xml.2012-11-16T23\:50\:04+01\:00.diff
00000000  72 73 02 36 46 00 04 35  00                       |rs.6F..5.|
--------------------

But this is not the most important as preventing rdiff-backup viewing 
changes shall prevent also these increments to be stored.

So question is : why are these "uname" once here and once gone ?

I see 4 main differences between the working system and this one that 
could lead to that :
 - Hard drive is a RAID 1 (working system doesn't have RAID), but I don't 
think it is the reason as it is pure hardware, and there is the FS over.
 - Source partition is ext4 (working system is ext3).
 - Owners (i.e. uname) are LDAP users and LDAP server isn't on the faulty 
machine (it is on the working one). So users are not listed in the 
/etc/passwd file.
 - Kernel is 2.6 (working system is 3.2) and maybe one of the above 
characteristics (or another one) is badly managed by 2.6 kernels.

Here I'm not a specialist, so if someone can help in finding the root 
cause, that could be very fine. ;-)

Anyway thanks a lot for already provided very helpful answers.

Best regards,
Matthieu

> > I've got some more clues after this weekend.
> >
> > Of course, nobody has connected to the machine (i.e. open a session)
> > during the weekend.
> > But on each evening when backup was running, the complete (on almost
> > complete) /home/ folder of one (and only one) of the users was viewed 
by
> > rdiff-backup as changed (in the same way I described in my former 
email,
> > i.e. a IncrementSize of some bytes&  no actual change).
> >
> > Should I suspect some Kubuntu service to create this weird things ?
> > (something like updatedb.mlocate, even if I doubt on this particular 
one).
> 
> It doesn't seem likely that a user would have a home directory 
consisting
> almost entirely of files with multiple hard links, so it would seem that
> something else is going on.
> 
> Besides the SHA1Digest (which is not used for detecting whether a file 
has
> changed), the only metadata that rdiff-backup records for an ordinary 
file
> with just a single hard link is size, mtime, UID, uname, GID, gname, and
> permissions.  Services that run around creating indexes of files 
wouldn't
> be changing any of that.
> 
> Take a look at the mirror_metadata.{timestamp}.{diff|snapshot}.gz file 
for
> the prior day and compare the stored data for one of the "changed" files
> with what is stored in the current 
mirror_metadata.{timestamp}.snapshot.gz.
> (I generally open a couple windows and use _zless_ on each file to do 
that,
> searching for for the pathname.)  If rdiff-backup thinks something 
changed,
> there should be a difference there.
> 
> -- 
> Bob Nichols     "NOSPAM" is really part of my email address.
>                  Do NOT delete it.
> 
> 
> _______________________________________________
> rdiff-backup-users mailing list at address@hidden
> https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> Wiki URL: 
http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki