Here is a link to the photo: http://home.ausiv.com:85/P5220001.JPG. Bear in mind that this is happening with lots of files (maybe even a majority of them). If I can get a copy of the version from my dad, I'll post it as well.
Thanks for all the help. - Austin On Wed, Feb 11, 2009 at 3:18 PM, Austin Roberts <[email protected]> wrote: > Sorry, I just noticed there is an update to this thread. I can send you the > version of the photo that is in the repository (and will when I get home > this evening). I will see if my dad can send me the version of the photo > from his computer (that's what I was trying to back up, and I'm no longer in > the same town as that machine). As I said earlier, both files have the same > md5sum, so I'm not sure what differences there could be. > > Look for an update tonight. > > - Austin > > > On Thu, Feb 5, 2009 at 3:16 PM, Andrew Ferguson <[email protected]>wrote: > >> Robert, >> >> That's a very interesting diff file ... it consists only of copy commands, >> including several which are duplicated over and over. >> >> Do you think you could send me the photograph, both the version that is on >> the source machine and the version on the repository? >> >> I believe librsync is choking on it. >> >> >> thanks, >> Andrew >> >> >> >> On Feb 1, 2009, at 4:01 PM, Austin Roberts wrote: >> >> >> First, here is the original discussion: >> >> >> http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/rdiff-backup-23/rdiff-creating-a-patch-file-when-there-are-no-changes-to-th-63313/ >> >> Second >> I'm running rdiff-backup 1.2.5 on both systems. The windows system is >> using the native windows binary. On the windows PC, I am running >> rdiff-backup, using plink.exe for the remote schema, and backing up C:\\ to >> a folder on the linux PC. >> >> Most of the diffs are not gzipped. I assume they were small enough that >> the gzip overhead would make them bigger, so somewhere something decided not >> to compress the files. A few of the larger files have diffs large enough to >> be compressed. >> >> Using a photograph and diff that I can provide upon request, the md5sum >> for both the source and the destination file is >> 834c6f37ad3b53942d5842a97fce5df0. The hexdump of the diff is >> >> 0000000 7372 3602 0046 8008 064a 0260 4a20 6006 >> 0000010 2002 064a 0260 4a20 e00e 4015 064a 0260 >> 0000020 4a20 6006 2002 064a 0260 4a20 6006 2002 >> 0000030 064a 0260 4a20 6006 2002 064a 0260 4a20 >> 0000040 6006 2002 064a 0260 4b20 4037 0400 f85f >> 0000050 0000 >> 0000051 >> >> The file is 293.8 KB. >> >> Thanks for the help. >> >> - Austin >> >> PS: Andrew, sorry about the duplicate. I always forget to hit reply all >> and send to the list. >> >> >> On Sun, Feb 1, 2009 at 9:30 AM, Andrew Ferguson <[email protected]>wrote: >> >>> >>> On Feb 1, 2009, at 10:23 AM, Austin Roberts wrote: >>> >>>> I'm doing a backup (from Windows to Linux, though I'm not sure that's >>>> relevant), and I've noticed that a lot of files (especially pictures) that >>>> haven't changed at all are being incremented. It will say "Processing >>>> changed file ..." "Incrementing mirror file ..." Even though the file >>>> hasn't >>>> changed at all. The resulting diffs are generally between 9 and 141 bytes. >>>> >>> >>> Backing up from Windows to Linux is relevant because rdiff-backup >>> inspects the metadata on the file to determine whether it has changed and >>> should be backed up. Getting the algorithm right becomes more complicated >>> with platforms as different as Windows and Linux. >>> >>> In order to help you, you're going to have to describe your situation >>> some more. What version of rdiff-backup are you running on each end? Is it >>> the native Windows client or the Cygwin client? How are you doing the >>> backup? If you gunzip one of the diff.gz files, what does it say? (it will >>> be in binary, use hexdump) ... What does md5 report for the "different" >>> files? How large are the files which are being marked as "changed"? >>> >>> >>> I found a discussion of this from 2004, and the consensus seemed to be >>>> that these were unique rsync deltas, even though the file hadn't changed. >>>> Someone fixed it by doing md5sums of the files on each side to make sure >>>> they were different before storing anything. >>>> >>> >>> Can you send a link to that discussion? Given it's age, it's probably not >>> relevant to your particular situation. The rdiff-backup code has changed a >>> lot in the last five years. >>> >>> >>> thanks, >>> Andrew >>> >> >> >> _______________________________________________ >> rdiff-backup-users mailing list at [email protected] >> http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users >> Wiki URL: >> http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki >> >> >> >
_______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
