Bug with binary file backup.

Ben Escoto bescoto@stanford.edu
Wed, 06 Feb 2002 14:55:58 -0800

Content-Type: text/plain; charset=us-ascii

>>>>> "DS" == Dan Sturtevant <dsturtev@plogic.com>
>>>>> wrote the following on Wed, 6 Feb 2002 16:40:50 -0500 (EST)

  DS> Thanks in advance for the help.  I just began trying to use
  DS> rdiff-backup today.  It seems to fit my needs very well.

  DS> I did have one problem.  Given ./dirA/ and ./dirB/ directories
  DS> and binary files ./dirA/bin.img and ./dirB/bin.img.

  DS> I do: rdiff-backup ./dirA ./backup

  DS> Then: rdiff-backup ./dirB ./backup

  DS> ./backup at this point should be identical to ./dirB with the
  DS> exception of the existence of the ./backup/rdiff-backup-data.

  DS> However, if a binary file present under ./dirA and ./dirB has
  DS> the same name, path, and filesize, it is not replaced.  I then
  DS> have a tree that is identical to ./dirB except for the binary
  DS> file from dirA.

rdiff-backup should also look at the file's modification time to
determine if it is different.  But if the file has the same:

modification time

(basically everything you can tell without reading the file into
memory) then rdiff-backup cannot tell that it is different and will
not replace the file.  At least this is the way it is supposed to
work---let me know if you are seeing different behavior.

    The alternative would be to read each file into memory and
send over a hash/digest.  I decided not to things this way because
it would take much longer and I assumed the current way would be
adequate (especially because of the mod time checking).

    If in fact the two different files have the same modification
time, how is this happening?  Is some application changing the file
and deliberately restoring the old mtime?

Ben Escoto

Content-Type: application/pgp-signature

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001