Re: [rdiff-backup-users] Suggestion for documentation change

[dean gaudet]

sounds like the bug is that rdiff-backup decides there's a metadata change 
and stores an almost-empty .diff.gz file even though it's not required.  
even though the metadata change is innocuous...

seems like it would be possible to at least avoid the almost-empty patch 
file when there is a metadata-only change.

in fact the problem happens for other metadata-only changes... such as 
chown/chmod.

worth fixing if someone has the time :)

easier to fix the almost-empty .diff.gz file problem than it is to figure 
out if a filesystem lacks persistent inode information.

-dean

On Wed, 15 Nov 2006, Michael Stucki wrote:

> Hi folks,
> 
> I just managed to work around a big problem, and I thought it would be good
> to let you know about:
> 
> I was trying to backup a collection of mounted SMB shares on a Linux system.
> In the first run, this worked very well, but after that I've encountered a
> big problem:
> 
> Although nothing changed on any of those shares, rdiff-backup incremented a
> lot of files, just randomly as it seemed to me. The diff files of these
> increments were always just a few bytes, they didn't contain any noticable
> changes inside.
> 
> After all I've found out that the "--no-compare-inode" option solves this
> problem. As it seems, remounting a share causes a change of the inode data
> (though there is nothing stored on inodes since the system is remote...)
> 
> Since the man-page didn't mention anything about this, and I didn't see
> anybody else reporting this problem, I thought it would be good to let you
> know about this little workaround...
> 
> - michael
> 
> 
> 
> _______________________________________________
> rdiff-backup-users mailing list at address@hidden
> http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
>