adm-zip
adm-zip copied to clipboard
Error: RangeError [ERR_OUT_OF_RANGE]

"adm-zip": "^0.5.9"
internal/buffer.js:72 throw new ERR_OUT_OF_RANGE(type || 'offset', ^
RangeError [ERR_OUT_OF_RANGE]: The value of "offset" is out of range. It must be >= 0 and <= 22. Received 23
at boundsError (internal/buffer.js:72:9)
at Buffer.readUInt16LE (internal/buffer.js:229:5)
at parseExtra (/Users/darmin/workspace/OnTheWay/jstest/test-zip/node_modules/adm-zip/zipEntry.js:158:25)
at Object.set extra [as extra] (/Users/darmin/workspace/OnTheWay/jstest/test-zip/node_modules/adm-zip/zipEntry.js:218:13)
at readEntries (/Users/darmin/workspace/OnTheWay/jstest/test-zip/node_modules/adm-zip/zipFile.js:55:29)
at Object.get entries [as entries] (/Users/darmin/workspace/OnTheWay/jstest/test-zip/node_modules/adm-zip/zipFile.js:123:17)
at Object.getEntries (/Users/darmin/workspace/OnTheWay/jstest/test-zip/node_modules/adm-zip/adm-zip.js:474:32)
at Object.
I also saw this happen in one of my huge processes.
The project I'm working on wants a massive zip of a bunch of their PDFs. By a bunch, I mean 15K+ PDFs with final pre-compression amount of 2.5GB+. It's a Civil Engineering firm and all these reports correspond to work done over the course of at least a year.
Due to the size of the number, I have a feeling I've hit an overflow issue and will probably batch these reports up in groups of 5K for now.
Regardless, I assume a more customized error should be thrown back
I have the same problem. Here is a minimal example using extractAllTo
:
// asdf.ts
import AdmZip from 'adm-zip';
const z = new AdmZip('myFile.zip');
z.extractAllTo('./temp', true);
And here is the output:
$ npx ts-node asdf.ts
RangeError [ERR_OUT_OF_RANGE]: The value of "offset" is out of range. It must be >= 0 and <= 22. Received 23
at new NodeError (node:internal/errors:387:5)
at boundsError (node:internal/buffer:86:9)
at Buffer.readUInt16LE (node:internal/buffer:243:5)
at parseExtra (/home/kkovacs/oss_97542/node_modules/adm-zip/zipEntry.js:158:25)
at Object.set extra [as extra] (/home/kkovacs/oss_97542/node_modules/adm-zip/zipEntry.js:218:13)
at readEntries (/home/kkovacs/oss_97542/node_modules/adm-zip/zipFile.js:55:29)
at Object.get entries [as entries] (/home/kkovacs/oss_97542/node_modules/adm-zip/zipFile.js:123:17)
at Object.extractAllTo (/home/kkovacs/oss_97542/node_modules/adm-zip/adm-zip.js:604:18)
at Object.<anonymous> (/home/kkovacs/oss_97542/asdf.ts:3:3)
at Module._compile (node:internal/modules/cjs/loader:1120:14) {
code: 'ERR_OUT_OF_RANGE'
}
I can unzip the file on my computer just fine, so I don't think it's corrupted. The zip file is about 280KB, so it shouldn't be a size issue either.
For anyone else with this problem, my current workaround is to just not use this package 😢. I can achieve the desired result using this:
import childProcess from 'child_process';
childProcess.execSync('unzip -d ./temp -o myFile.zip');
Would be nice to use adm-zip here, but for now I will have to just use unzip
in a child process.
Same issue as @dallenbaldwin with length
property
Do you have any updates or do you have any suggestions to give more information?
Same issue as @dallenbaldwin with
length
property Do you have any updates or do you have any suggestions to give more information?
I eventually moved to a different package and refactored my code: zip-a-folder
has worked great so far. It's dead simple and "just works"
Thanks @dallenbaldwin, I think I have to migrate my code too.
Anybody looking for zip-a-folder
repo:
https://github.com/maugenst/zip-a-folder
After some investigation, I have figured out what went wrong for me. Hopefully this will help others. The issue in my case was that the "LastModifiedTime" and "CreatedTime" were the default 1979 timestamps. I used BulkFileChanger (https://www.nirsoft.net/utils/bulk_file_changer.html) to edit all my files to have a new time. This fixed it for me.
This happened because I copied items directly from another archive without unzipping first.
I figured this out by observing the exception happen on line 256.
After some investigation, I have figured out what went wrong for me. Hopefully this will help others. The issue in my case was that the "LastModifiedTime" and "CreatedTime" were the default 1979 timestamps. I used BulkFileChanger (https://www.nirsoft.net/utils/bulk_file_changer.html) to edit all my files to have a new time. This fixed it for me. This happened because I copied items directly from another archive without unzipping first. I figured this out by observing the exception happen on line 256.
Not my case.
It seems to work now in 0.5.12 it was fixed in PR #449