Error: RangeError [ERR_OUT_OF_RANGE]

[DarminZ]

"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. (/Users/darmin/workspace/OnTheWay/jstest/test-zip/index.js:12:6)
at Module._compile (internal/modules/cjs/loader.js:776:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)

[DarminZ]

source.zip

[dallenbaldwin]

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

[nullromo]

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.

[nullromo]

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.

[alitoufighi]

Same issue as @dallenbaldwin with length property
Do you have any updates or do you have any suggestions to give more information?

[dallenbaldwin]

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"

[alitoufighi]

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

[TheRedstoneScientist]

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.

[LasyIsLazy]

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.

[5saviahv]

It seems to work now in 0.5.12
it was fixed in PR #449