Bug with binary file backup.
Wed, 06 Feb 2002 15:58:16 -0800
Content-Type: text/plain; charset=us-ascii
>>>>> "DS" == Dan Sturtevant <firstname.lastname@example.org>
>>>>> wrote the following on Wed, 6 Feb 2002 18:33:26 -0500 (EST)
DS> What I was doing was maintaining a tree of the original
DS> distribution (Plogic-7.1-5) that I was working with and then
DS> creating deltas by running #rdiff-backup Plogic-7.1-6/ backup/
DS> followed by #rdiff-backup Plogic-7.1-5 backup/
DS> I had hoped that this would create a directory structure that
DS> the end user could place into a copy of the original
DS> Plogic-7.1-5 tree to get it up to Plogic-7.1-6.
DS> This creates the opposite problem: I want older timestamps from
DS> Plogic-7.1-5 to be pushed on top of Plogic-7.1-6 to generate the
DS> rdiff-backup-data directory. It will almost always be the case
DS> that older files should replace newer ones in my case.
Ok, I can think of 4 things that you could try:
1. Use my program. The problem you ran into was that files seemed
DS> My test directories had the same time because they were coppied
DS> over to my local machine at the same time.
So, it seems if you waited a second (e.g. cp ...; sleep 1; cp
....) your immediate problem would go away.
2. Instead of using CVS use something like PRCS (?) which is better
at taking binary differences.
3. I seem to remember someone contributing an extension to rsync
called rsync+. I don't know if it has been adopted yet, or how
stable it is, but the idea is to save the information between
rsync sessions. For instance, suppose server 1 always changes,
and servers 2 and 3 are supposed to be identical copies of 1. I
think rsync+ could be run on 1 and 2, and then would produce a
file that could be transmitted to 3, so 3 could be updated without
rereading all the files on 1 again.
4. Make a big tar (uncompressed; just tar) file like Plogic-7.1-5.tar
or Plogic-7.1-6.tar and then run rdiff on those two files. You
can compress the diff and send it around.
I don't know your situation very well, but I would try (4) first, then
(3) if it is stable and easy to use, then (1) and then (2).
DS> You seem to have a great deal of experience in this domain.
Yep, on the internet no one knows that you're a dog. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001
-----END PGP SIGNATURE-----