-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
zlib.createGunzip "unknown compression method" #5852
Comments
@evanlucas @thealphanerd ... possible zlib regression in v5.9? Could #5120 be to blame? @dpicky ... can you provide an example test case that demonstrates the problem reliably? |
More details would be useful. Straightforward use case does not have this problem as far as I can tell:
|
@dpicky Could you give us some more info on what sort of files these are? |
@Fishrock123 I have same issue on |
Just checked, this definitely was introduced in f380db2. |
I can reproduce this by passing the gcc-5.3.0 tarball to const fs = require('fs');
const zlib = require('zlib');
let l = 0;
fs.createReadStream('gcc-5.3.0.tar.gz')
.pipe(zlib.createGunzip())
.on('data', d => l += d.length);
process.on('exit', () => console.log(l)); results in
|
/cc @kthelgason |
I think I got this, PR incoming. 😄 |
Add test files that reliably reproduce nodejs#5852. The gzipped file in test/fixtures/pseudo-multimember-gzip.gz contains the gzip magic bytes exactly at the position that node encounters after having read a single block, leading it to believe that a new data member is starting.
Only treat the gzip magic bytes, when encountered within the file after reading a single block, as the start of a new member when the previous member has ended. Fixes: nodejs#5852
Only treat the gzip magic bytes, when encountered within the file after reading a single block, as the start of a new member when the previous member has ended. Add test files that reliably reproduce #5852. The gzipped file in test/fixtures/pseudo-multimember-gzip.gz contains the gzip magic bytes exactly at the position that node encounters after having read a single block, leading it to believe that a new data member is starting. Fixes: #5852 PR-URL: #5863 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Only treat the gzip magic bytes, when encountered within the file after reading a single block, as the start of a new member when the previous member has ended. Add test files that reliably reproduce #5852. The gzipped file in test/fixtures/pseudo-multimember-gzip.gz contains the gzip magic bytes exactly at the position that node encounters after having read a single block, leading it to believe that a new data member is starting. Fixes: #5852 PR-URL: #5863 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
A bug was introduced in node v5.9 that causes lots of "unknown compression method" errors, see nodejs/node#5852 Hopefully this is fixed in the next patch release.
Hi,
Cheers. |
@thomasmodeneis Fixed in 6.0.0 and above. |
Since upgrading to 5.9.0 getting lots of "unknown compression method" errors when trying to uncompress files (using zlib.createGunzip) that work in previous versions of Node include 5.8
The text was updated successfully, but these errors were encountered: