-
Notifications
You must be signed in to change notification settings - Fork 12
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
Decompressed file content is messed up #32
Comments
Attaching my code: Zip:
Unzip:
|
Hi @assafavital Can you check if v0.1.5 of fastzip also has this same problem? It might be a regression with the latest versions. Are you able to put together a zip file (using the zip utility, to avoid the issues mentioned here), whose contents compressed with Thank you for the report and help diagnosing this! |
This problem is present in v0.1.5 as well. |
Does this occur if you pass the option I'd have expected there to be a checksum error if what you're decompressing isn't correct. |
Works well with the suggested option. |
That does take away some of the benefits of using fastzip though. In order to perform parallel zip compression, we compress several files to individual files on disk and then read back the compressed content of each to add to the archive serially. You're the only one that has reported a problem with this technique. Can you tell me more about your OS/disk etc? If it occurs on the cloud VMs, maybe I can replicate it. |
I'm using fastzip inside an I'll try some more |
@saracen Just ran into this myself, seems to happen if you use a more up2date version of klauspost/compress. When using the go.mod listed 1.13.5, it works fine, if using the current 1.13.6 I have the same gibberish result as @assafavital. This can happen if blindly used |
Thank you for this! |
This also now calls the newer CreateRaw() method, as CreateHeaderRaw() is now deprecated. This fixes #32, as when CreateHeaderRaw() was deprecated, it started calling the incorrect function that replaced it: klauspost/compress#502 A test with a larger content body has been added as it was able to detect this regression. Fixes #32
Thanks everybody for reporting this. Fix is now in the main branch and I'll tag a new release ( |
I'm archiving a folder containing
.git/config
file withfastzip
on Linux, following the example shown in README.When extracting said file, I'm expecting to see:
However, I get:
This happens with both golang sdk (using
NewExtractor
) and with traditional unixtar
command.Worth mentioning, is that this is only the case when using the default
Deflate
compression method. Using0
(Store) method works fine (no compression though, which is expected).I'd appreciate any help with this issue.
EDIT: Compressing only the file itself (as opposed to the folder containing it) seems to work fine.
The text was updated successfully, but these errors were encountered: