I have two ~300MB .7zipped files with database dumps that, if
unzipped, would become ~30G in size each. Given that, I'd like
to avoid having to uncompress them, so I did this:
7z e -so first.7z > first &
7z e -so second.7z > second &
xdelta3 -s first second > delta # delta turns out ~8GiB
But what I get are tons of warning saying "input
window xxxx....yyyyy has no source copies'. The delta
gets generated, but they are two orders of magnitude
larger than what I get if I do:
7z e -so first.7z > realfirst # realfirst is ~30GiB
7z e -so second.7z > realsecond # realsecond is also ~30GiB
xdelta3 -s realfirst realsecond > delta # delta comes at about 30MiB
The 'memory tuning' page on xdelta's web site says that
the input buffer allows the data to come sequentially without
seeking backwards and the source code also mentions something
about that and the possibility of the inputs coming from fifos,
so I'd guess it should be possible at least in principle.
So my question is: how viable would it be to add support for having
the file specified in the -s parameter to come from a FIFO at least
for the delta generation operation?
Original issue reported on code.google.com by kikocar...@gmail.com on 19 Dec 2007 at 6:18
The text was updated successfully, but these errors were encountered:
Your first example seems to be quite dangerous. :)
It's true that the encoder reads sequentially, so this should be possible.
The only thing is that it uses the source size to determine some parameters.
However, this is not a real obstacle. So I'll say that this isn't very hard and
should be done.
Original comment by josh.mac...@gmail.com on 19 Dec 2007 at 6:51