Bug with binary file backup.
Wed, 6 Feb 2002 19:00:36 -0500 (EST)
Let me revise what I just said.
The only file that produced this problem had the same timestamp. This is
because it was the boot288.img on a cd. We modify it by mounting it
loopback and changing a file inside it. This meant that although the file
is changing, the inode's time is not. I have updated our scripts to touch
the .img file each time. Other than that, it appears that going with an
earlier time works.
I haven't evaluated it for long, but this package looks great. Thanks.
BTW, how robust is it in terms of dealing with symlinks? Does this
operate in the same way an rsync -a?
On Wed, 6 Feb 2002, Dan Sturtevant wrote:
> My test directories had the same time because they were coppied over to my
> local machine at the same time.
> What I am trying to do is the reverse of backups acutally.
> I work for a beowulf company and am trying to set up a system by which our
> distribution can sit on an iso on the web followed by deltas that can be
> applied to the original so that people dont have to download the whole iso
> or tree again.
> CVS isnt a great fit because most of the stuff on the iso is RPMS.
> rsync would be fine except that I didnt want to have to store all
> revisions of the distro (it will be updated 3 times a week) on the
> Your program seems like a promising alternative.
> What I was doing was maintaining a tree of the original distribution
> (Plogic-7.1-5) that I was working with and then creating deltas by running
> #rdiff-backup Plogic-7.1-6/ backup/
> followed by
> #rdiff-backup Plogic-7.1-5 backup/
> I had hoped that this would create a directory structure that the end user
> could place into a copy of the original Plogic-7.1-5 tree to get it up to
> This creates the opposite problem: I want older timestamps from
> Plogic-7.1-5 to be pushed on top of Plogic-7.1-6 to generate the
> rdiff-backup-data directory. It will almost always be the case that older
> files should replace newer ones in my case.
> You seem to have a great deal of experience in this domain.
> What do you feel would be the best approach for solving this kind of
> Dan Sturtevant
> On Wed, 6 Feb 2002, Ben Escoto wrote:
> > >>>>> "DS" == Dan Sturtevant <firstname.lastname@example.org>
> > >>>>> 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
> Rdiff-backup mailing list