Bug with binary file backup.

[Dan Sturtevant]

Ben,

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?

Thanks,
Dan





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
> 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
> >
>
> _______________________________________________
> Rdiff-backup mailing list
> Rdiff-backup@keywest.Stanford.EDU
> http://keywest.Stanford.EDU/mailman/listinfo/rdiff-backup
>