-
Notifications
You must be signed in to change notification settings - Fork 976
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
Can't untar result file #382
Comments
I have not gone through and fixed the tar/gzip examples, there might be something about them that is not quite right for the newer versions (they were written for 0.8*). |
Just wanted to add I am experiancing the same problem. Updated the SharpZipLib in my project from version 1.1 to version 1.2. Creating a plain tar file still works as expected but creating a tar.gz file (using gzipoutputstream) the resulting file does not working / is not extractable. Kind regards, Ferry |
I tried testing it, and what seems to be happening is that flushing GZipOutputStream before writing anything to it causes something to go wrong. This test without using Tar at all seems to show the issue:
(It seems ok without the flush). Caused by the changes to DeflatorOutputStream.Deflate in #225 perhaps? |
(The underlying issue with the corrupt gzip file might be because the call to DeflatorOutputStream.Flush causes it to write some data to the output stream before GZipOutputStream has written the Gzip header, so the produced stream can't then be read.) Not sure how much of that is a deflate issue and how much is down to the way GZipOutputStream handles writing the headers - would it be reasonable for GZipOutputStream to ensure the headers are written before any flush on the base deflator stream occurs? |
@piksel Any thoughts on the effects of adding something like
to GZipOutputStream ? |
Yeah, that would be my initial solution as well. Of course, it could still be the case that the header could be written before it's fully finalized by the consumer. But in that case, this would still fail using the current code. There is no reason to ever want to write the contents before the header, so this should be an improvement in any case. |
In TarArchive.Dispose, it does
and TarOutputStream.Flush flushes the underlying output stream (I think TarOutputStream.Dispose then writes more data to the stream and flushes again, so I'm not entriely sure if the initial flush is needed in this situation) |
This all has to do with #225 and how the Deflate engine handles an empty buffer (not well). |
…efore flush * Add unit tests to repro #382 * Add an override of Flush() to GZipOutputStream to ensure the headers is writen before flushing
Hi, will this be fixed in the next version? I think my problems are related: Since updating on 1.2.0 tar.gz-archives are corrupt when they are quite small. |
@aluidasa version 1.3 is out now and should contain the fix for this, if you want to give it a try? |
Perfect :) Thank you guys so much! |
Steps to reproduce
tar -C ./ -xvf /mnt/c/work/temp/Haludi8.tar.gz
Expected behavior
When I use version 1.1.0 the operation works
and I can untar the result file
Actual behavior
I get an error
Version of SharpZipLib
1.2.0
Obtained from (only keep the relevant lines)
The text was updated successfully, but these errors were encountered: