New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect delta w/ 1.1.4 (very small files) #17

Closed
GoogleCodeExporter opened this Issue Mar 24, 2015 · 5 comments

Comments

Projects
None yet
1 participant
@GoogleCodeExporter

GoogleCodeExporter commented Mar 24, 2015

https://sourceforge.net/tracker/?func=detail&atid=106966&aid=663268&
group_id=6966

I *thought* I tried to reproduce this once, and failed. The reporter says
it is still broken.


Original issue reported on code.google.com by josh.mac...@gmail.com on 1 Feb 2007 at 6:36

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 24, 2015

When I run 1.1.4 on your input, I get an error -- and no patch is output.  The 
exit
status is 2. No error message is printed, so this is definitely an encoder bug
(somehow, for this 16 byte input, it produces an invalid encoding). Running 
"xdelta
delta -0" I get the same input as yours, but I do not get an output from "xdelta
patch". In SVN 100 (at http://xdelta.googlecode.com/svn/trunk/xdelta1/) I've at 
least
fixed the decoder to report the parse error.

Original comment by josh.mac...@gmail.com on 2 Feb 2007 at 6:41

GoogleCodeExporter commented Mar 24, 2015

When I run 1.1.4 on your input, I get an error -- and no patch is output.  The 
exit
status is 2. No error message is printed, so this is definitely an encoder bug
(somehow, for this 16 byte input, it produces an invalid encoding). Running 
"xdelta
delta -0" I get the same input as yours, but I do not get an output from "xdelta
patch". In SVN 100 (at http://xdelta.googlecode.com/svn/trunk/xdelta1/) I've at 
least
fixed the decoder to report the parse error.

Original comment by josh.mac...@gmail.com on 2 Feb 2007 at 6:41

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 24, 2015

Original comment by josh.mac...@gmail.com on 2 Feb 2007 at 8:46

  • Changed title: Incorrect delta w/ 1.1.4 (very small files)

GoogleCodeExporter commented Mar 24, 2015

Original comment by josh.mac...@gmail.com on 2 Feb 2007 at 8:46

  • Changed title: Incorrect delta w/ 1.1.4 (very small files)
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 24, 2015

I figured this out. In case you didn't realize, your inputs (16-1.bin and 
16-2.bin)
have gzip headers but are invalid inputs for gzip.  Xdelta supports "externally
compressed" gzip inputs (read more about external compression in 3.x here:
http://code.google.com/p/xdelta/wiki/ExternalCompression).

Xdelta-1.1.4 and earlier did not check the return value from gzclose(), so 
invalid
gzip inputs caused invalid patch outputs from "xdelta delta". This is fixed in 
SVN
103 and will be released with 1.1.5.  In the meanwhile, to correctly process 
invalid
gzip inputs you can pass the -p flag to disable external compression.

Original comment by josh.mac...@gmail.com on 2 Feb 2007 at 7:52

  • Changed state: Fixed

GoogleCodeExporter commented Mar 24, 2015

I figured this out. In case you didn't realize, your inputs (16-1.bin and 
16-2.bin)
have gzip headers but are invalid inputs for gzip.  Xdelta supports "externally
compressed" gzip inputs (read more about external compression in 3.x here:
http://code.google.com/p/xdelta/wiki/ExternalCompression).

Xdelta-1.1.4 and earlier did not check the return value from gzclose(), so 
invalid
gzip inputs caused invalid patch outputs from "xdelta delta". This is fixed in 
SVN
103 and will be released with 1.1.5.  In the meanwhile, to correctly process 
invalid
gzip inputs you can pass the -p flag to disable external compression.

Original comment by josh.mac...@gmail.com on 2 Feb 2007 at 7:52

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 24, 2015

IIRC (it is four years) I was making a patch of a bigger file,
but xdelta failed...  Then I made a little "test case", 16 bytes,
for you.

But it shouldn't matter what the input is,
xdelta should just work (TM).
Be it valid or invalid gzip or jpeg or torrent.
Good if 1.1.5 works this way.

Original comment by usenetha...@gmail.com on 2 Feb 2007 at 8:35

GoogleCodeExporter commented Mar 24, 2015

IIRC (it is four years) I was making a patch of a bigger file,
but xdelta failed...  Then I made a little "test case", 16 bytes,
for you.

But it shouldn't matter what the input is,
xdelta should just work (TM).
Be it valid or invalid gzip or jpeg or torrent.
Good if 1.1.5 works this way.

Original comment by usenetha...@gmail.com on 2 Feb 2007 at 8:35

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 24, 2015

You will need to pass -p for 1.1.5 to work on invalid gzipped inputs, you can 
use -p
on 1.1.4 and it will just work. I'll make a release next weekend or so.

Original comment by dotdotis...@gmail.com on 2 Feb 2007 at 8:45

GoogleCodeExporter commented Mar 24, 2015

You will need to pass -p for 1.1.5 to work on invalid gzipped inputs, you can 
use -p
on 1.1.4 and it will just work. I'll make a release next weekend or so.

Original comment by dotdotis...@gmail.com on 2 Feb 2007 at 8:45

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment