Bug with binary file backup.
Ben Escoto
bescoto@stanford.edu
Wed, 06 Feb 2002 14:55:58 -0800
--==_Exmh_1882869180P
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:
name
path
filesize
modification time
permissions
ownership
(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
--==_Exmh_1882869180P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001
iD8DBQE8YbR8+owuOvknOnURAjqYAJ0cCq8unfWyt2odsZ5mb2O9PhvFNwCggpG7
LyBU5m19YcaknkqWPuF6xr4=
=B+MO
-----END PGP SIGNATURE-----
--==_Exmh_1882869180P--