Bug with binary file backup.

[Dan Sturtevant]

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
webserver.

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
Plogic-7.1-6.

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
problem?

Thanks,
Dan Sturtevant










On Wed, 6 Feb 2002, Ben Escoto wrote:

> >>>>> "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
>