rsync and rawhide

Chris Ricker kaboom at gatech.edu
Sat Oct 18 14:01:51 UTC 2003


On Fri, 17 Oct 2003, Mark Mielke wrote:

> I would prefer to use rsync to update my rpm set with rawhide simply because
> it communicates the information more efficiently. Lately using 'lftp mirror'
> I've noticed that packages sometimes download on top of themselves, perhaps
> just because the timestamp of the file has changed?

At one point, the machines in the load balance often timestamped files an 
hour apart. Depending on which box you hit when you did the DNS query, you'd 
be an hour ahead or an hour behind, and have to mirror everything again. I 
don't know if that's still the case, since I just picked one and stick with 
it now.

> Even if the RPM had changed (signed after the fact?), rsync would do a
> better job than ftp.

That's actually what got me thinking about this. I noticed I was downloading 
all of XFree86 again b/c it was unsigned two days ago, and signed one day 
ago, so I got it both times.

> Note, though, that just because the change was only 4 lines of text, does not
> mean that the whole RPM won't need to be downloaded. I was under the
> impression that rsync communicates block checksums back and forth. How would
> it handle the entire file from offset 4096 being shifted 512 bytes longer
> or shorter? Would it not re-transfer the whole file?

Not as I understand it. I think the way rsync works is one side blocks, 
checksums, then sends the checksums to the other side. The other side then 
does sliding checksums across all possible blocks (not just blocks at 
corresponding offsets) to find the matching blocks, even if they've shifted 
to a different offset....

> Also, I think one could argue that rsync should have an option to deal with
> this situation - file content not significantly changing, but file name
> changing. At *least* for files in the same directory.

That's a problem solvable outside of rsync, though. And maybe doing so is 
better than asking RH to make pseudo-ISOs?

later,
chris





More information about the fedora-devel-list mailing list