Comments

What steps will reproduce the problem?
1.use commandline xdelta3.exe -0 -f -e -s src.file dst.file diff.file
2.
3.
What is the expected output? What do you see instead?
xdelta3: : XD3_TOOFARBACK
What version of the product are you using? On what operating system?
Monday, January 13, 2014
Re: Release 3.0.8
Please provide any additional information below.

Original issue reported on code.google.com by Qokelate@gmail.com on 28 Aug 2014 at 9:39

This comment has been minimized.

Similar problem.
What steps will reproduce the problem?
xdelta3.exe -0 -I 0 -B 1073741824 -W 16777216 -fves src.file dst.file diff.file
What version of the product are you using? On what operating system?
Revision 405 and revision 408 compiled with mingw-w64-v3.1.0, 32bit
architecture, Win7.
While making patch files for some 1GB files:
- revision 405 works without problems.
- revision 408 throws XD3_TOOFARBACK. I compiled it again with XD3_DEBUG=1, it
stops at this line:
https://code.google.com/p/xdelta/source/browse/trunk/xdelta3/xdelta3.c?spec=svn4
08&r=408#4710

Similar problem.
What steps will reproduce the problem?
xdelta3.exe -0 -I 0 -B 1073741824 -W 16777216 -fves src.file dst.file diff.file
What version of the product are you using? On what operating system?
Revision 405 and revision 408 compiled with mingw-w64-v3.1.0, 32bit
architecture, Win7.
While making patch files for some 1GB files:
- revision 405 works without problems.
- revision 408 throws XD3_TOOFARBACK. I compiled it again with XD3_DEBUG=1, it
stops at this line:
https://code.google.com/p/xdelta/source/browse/trunk/xdelta3/xdelta3.c?spec=svn4
08&r=408#4710

This comment has been minimized.

Why did this bug get closed?
Using the Windows x86 and also the x64 binary from the release page, I can reproduce the problem.
I could also provide a pair of files that trigger this problem if they would help.

Why did this bug get closed?
Using the Windows x86 and also the x64 binary from the release page, I can reproduce the problem.
I could also provide a pair of files that trigger this problem if they would help.

This comment has been minimized.

Basically I was trying to patch the .mp4 (which is the Big Buck Bunny 4k 60fps file I got from the linked site and tried to patch it to a .mkv (which was created by mkvmerge, though I didn't add subtitles or other streams to the .mkv in this example, just remuxed it with titles for the streams). It also happens with other .mp4 > .mkv files, but not with every file (I tested a 60MB file and it worked fine there).

Launching xdelta via cmd the following way:xdelta3-3.0.9-x64.exe -v -e -s bbb_sunflower_2160p_60fps_normal.mp4 bbb_sunflower_2160p_60fps_normal.mkv patch.vcdiff
I get this output and an incomplete patch file:

Patching the same files the same way with an older version without increasing the block size (3.0.2), xdelta doesn't abort and the patch works as intended, though using an increased block size (1GiB) provided by one of the bug reporters from Google Code (-B 1073741824), patching these two files works with 3.0.9, but it didn't worked for him, so maybe a bigger file triggers this problem also with this block size (I haven't tested it)?

Basically I was trying to patch the .mp4 (which is the Big Buck Bunny 4k 60fps file I got from the linked site and tried to patch it to a .mkv (which was created by mkvmerge, though I didn't add subtitles or other streams to the .mkv in this example, just remuxed it with titles for the streams). It also happens with other .mp4 > .mkv files, but not with every file (I tested a 60MB file and it worked fine there).

Launching xdelta via cmd the following way:xdelta3-3.0.9-x64.exe -v -e -s bbb_sunflower_2160p_60fps_normal.mp4 bbb_sunflower_2160p_60fps_normal.mkv patch.vcdiff
I get this output and an incomplete patch file:

Patching the same files the same way with an older version without increasing the block size (3.0.2), xdelta doesn't abort and the patch works as intended, though using an increased block size (1GiB) provided by one of the bug reporters from Google Code (-B 1073741824), patching these two files works with 3.0.9, but it didn't worked for him, so maybe a bigger file triggers this problem also with this block size (I haven't tested it)?

This comment has been minimized.

I forgot to mention in my comment earlier that I didn't test 3.0.8 or 3.0.6 but just randomly used 3.0.2, so maybe my testfiles would also pass without XD3_TOOFARBACK in 3.0.8, I don't know for sure though.

I forgot to mention in my comment earlier that I didn't test 3.0.8 or 3.0.6 but just randomly used 3.0.2, so maybe my testfiles would also pass without XD3_TOOFARBACK in 3.0.8, I don't know for sure though.

This comment has been minimized.

I mentioned 3.0.8 because the original issue was opened on 3.0.8.
On Apr 24, 2015 3:24 PM, "neappx" notifications@github.com wrote:

I forgot to mention in my comment earlier that I didn't test 3.0.8 or
3.0.6 but just randomly used 3.0.2, so maybe my testfiles would also pass
without XD3_TOOFARBACK in 3.0.8, I don't know for sure though since I
didn't test it.

I mentioned 3.0.8 because the original issue was opened on 3.0.8.
On Apr 24, 2015 3:24 PM, "neappx" notifications@github.com wrote:

I forgot to mention in my comment earlier that I didn't test 3.0.8 or
3.0.6 but just randomly used 3.0.2, so maybe my testfiles would also pass
without XD3_TOOFARBACK in 3.0.8, I don't know for sure though since I
didn't test it.

I forgot to mention in my comment earlier that I didn't test 3.0.8 or
3.0.6 but just randomly used 3.0.2, so maybe my testfiles would also pass
without XD3_TOOFARBACK in 3.0.8, I don't know for sure though since I
didn't test it.

I forgot to mention in my comment earlier that I didn't test 3.0.8 or
3.0.6 but just randomly used 3.0.2, so maybe my testfiles would also pass
without XD3_TOOFARBACK in 3.0.8, I don't know for sure though since I
didn't test it.

I forgot to mention in my comment earlier that I didn't test 3.0.8 or
3.0.6 but just randomly used 3.0.2, so maybe my testfiles would also
pass
without XD3_TOOFARBACK in 3.0.8, I don't know for sure though since I
didn't test it.

I forgot to mention in my comment earlier that I didn't test 3.0.8 or
3.0.6 but just randomly used 3.0.2, so maybe my testfiles would also
pass
without XD3_TOOFARBACK in 3.0.8, I don't know for sure though since I
didn't test it.

This comment has been minimized.

@mgrinzPlayer I usually develop with llvm tools (on OS X), then update both
gcc and llvm tools (on a Gentoo) and run build/test, and finally build on a
Windows 7 that I boot only rarely, using VSC++ 2010 Express.

I like your recommendation and have a mingw-w64-build running (on said
Gentoo).

@mgrinzPlayer I usually develop with llvm tools (on OS X), then update both
gcc and llvm tools (on a Gentoo) and run build/test, and finally build on a
Windows 7 that I boot only rarely, using VSC++ 2010 Express.

I like your recommendation and have a mingw-w64-build running (on said
Gentoo).

This comment has been minimized.

I've written one printf implementation (at work) and I refuse to do it
again. :-)

I'm running into trouble with the mingw tools, I wonder if you could share
a bit more about your build process. I'm getting linker errors as if the
tools aren't finding the basic mingw libraries. The mingw-w64-build script
works flawlessly, though. The script I'm using is here:

I've written one printf implementation (at work) and I refuse to do it
again. :-)

I'm running into trouble with the mingw tools, I wonder if you could share
a bit more about your build process. I'm getting linker errors as if the
tools aren't finding the basic mingw libraries. The mingw-w64-build script
works flawlessly, though. The script I'm using is here: