[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs

From: Robert Nichols
Subject: Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
Date: Sat, 17 Nov 2012 16:23:32 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121029 Thunderbird/10.0.10

On 11/16/2012 04:21 AM, address@hidden wrote:
Consider I already have 2 backups done on a daily basis (let me call them
A and B chronologically -- thus B is the current mirror).

I run 'rdiff-backup --compare' just before backing up : it returns "no

I run the back up and here rdiff-backup finds thousand of files that have
changed (viewed from session statistics) !!!
This backup is called C and is the new mirror.

When I look at the file statistics, a lot of files are marked as changed.
The first weird thing here is that IncrementSize is not null while
SourceSize and MirrorSize are identical (IncrementSize is always a small
number -<128 -).

For example : home/USER/.kde/share/config/katerc 1 67 67 66

By any chance are these all files with multiple hard links, and if so, does
this excerpt from the rdiff-backup manpage shed any light:

       This  option  prevents rdiff-backup from flagging a hardlinked file
       as changed when its  device  number  and/or  inode  changes.   This
       option  is  useful  in situations where the source filesystem lacks
       persistent device and/or inode  numbering.   For  example,  network
       filesystems  may  have  mount-to-mount  differences in their device
       number (but possibly stable inode numbers);  USB/1394  devices  may
       come  up at different device numbers each remount (but would gener-
       ally have same inode number); and there are filesystems which don’t
       even  have  the  same  inode  numbers from use to use.  Without the
       option rdiff-backup may generate unnecessary numbers of  tiny  diff

Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]