Does the rsync/xdelta algorithm *need* to write a new file?
Josh MacDonald
jmacd at CS.Berkeley.EDU
Thu May 23 07:32:01 EST 2002
Arthur,
I've added Randal Burns to the CC list on this reply. He has done
a lot of great research on in-place delta updates and will be
happy to provide further details, I'm sure. Short summary: You
can translate a traditional delta to be applied in-place with minor
loss of compression.
-josh
Quoting Arthur van Leeuwen (arthurvl at xos.nl):
> Hello,
>
> lately I've been playing with the idea of doing in-place updates
> of systems using either rsync or xdelta. However, both rsync
> and xdelta seem to be dead set on writing a new file first, and
> then atomically exchanging it with the old file.
>
> Now, as I want to apply a binary delta to a full filesystem, bigger
> than the available temporary space, this really makes rsync and
> xdelta extremely tough to use (I could work around it, only updating
> blocks of half the size of the temporary space at a time, but that
> would defeat some of the savings gotten by calculating a delta over
> the full filesystem: moves of data over block boundaries would incur
> extra overhead delta's)
>
> Has anybody thought about doing in-place patching of files using
> delta's?
>
> Another application where this would do wonders is people that rsync
> complete ISO images: they would not need to reserve space for an
> entire extra ISO on their systems.
>
> Doei, Arthur. (Wondering if it is at all possible...)
>
> --
> +- Arthur van Leeuwen, Systems Consultant, arthurvl at xos.nl -+
> | X/OS Experts in Open Systems BV |
> | Kruislaan 419 Phone: +31 20 6938364 |
> | 1098 VA Amsterdam Fax: +31 20 6948204 |
--
PRCS version control system http://sourceforge.net/projects/prcs
Xdelta storage & transport http://sourceforge.net/projects/xdelta
Need a concurrent skip list? http://sourceforge.net/projects/skiplist
More information about the rsync
mailing list