Uncaught TypeError: value is out of bounds

[adam-clason]

[Enter steps to reproduce below:]

1. ...
2. ...

Atom Version: 1.7.3
System: Mac OS X 10.10.3
Thrown From: Bart package, v1.1.0

Stack Trace

Uncaught TypeError: value is out of bounds

At buffer.js:825

TypeError: value is out of bounds
    at checkInt (buffer.js:825:11)
    at Buffer.writeUInt16LE (buffer.js:883:5)
    at getEndOfCentralDirectoryRecord (/Users/adamclason/.atom/packages/Bart/node_modules/yazl/index.js:220:10)
    at pumpEntries (/Users/adamclason/.atom/packages/Bart/node_modules/yazl/index.js:185:33)
    at ByteCounter.<anonymous> (/Users/adamclason/.atom/packages/Bart/node_modules/yazl/index.js:142:5)
    at emitNone (events.js:72:20)
    at ByteCounter.emit (events.js:166:7)
    at endReadableNT (_stream_readable.js:905:12)
    at doNTCallback2 (node.js:465:9)
    at process._tickCallback (node.js:379:17)

Commands

Config

{}

Installed Packages

# User
Bart, v1.1.0

# Dev
No dev packages

[SqrTT]

Hi @adam-clason,
Thank you for reporting this.
Could you specify steps to reproduce or describe when it happen, please?

[adam-clason]

It happens every time I try the "Upload all cartridges" option. It spins for some time then throws that error.

[SqrTT]

I still unable to reproduce this. :(
@adam-clason Could you provide more info? For example, platform version or project folders hierarchy, etc.
Is this occurs on current package version (1.2.2)?

[madzim]

@adam-clason The root cause is too many files.

I wrapped index.js line 220 with a simple try/catch and logged the value of self.entries.length.

In my case, the value was 68468 > UInt16 65535.

[SqrTT]

Folks, in this case you should try specify cartridges as described here. So this force uploading each directory/cartridge in other zip file.

cc @adam-clason @madzim

[SqrTT]

@adam-clason Do you have node_modules somewhere in project? Usually there is a lot of files. If yes, probably I can add ignore filter...

[adam-clason]

@SqrTT - I do

[madzim]

@SqrTT I see you posted a bug on YAZL. FWIW, the ZIP spec limits the number of files to 2 bytes (65535 files) See the "End of Central Directory Record" table towards the end of the wikipage: https://en.wikipedia.org/wiki/Zip_(file_format). The "solution" would be to create separate zip files.

[SqrTT]

@madzim It's sad I believed that this is limit of library. Thank you for clarification.

[SqrTT]

@adam-clason Could you please get version v1.2.3 and check if you can unload now, please?

[thejoshwolfe]

yazl just released version 2.4.0 which adds ZIP64 support. ZIP64 allows up to 2^32-1 entries in a zipfile, so your 68468 case should not be a problem. No API usage changes are required; it should just work if you update your dependencies.

According to my investigation, most popular zip file readers support the ZIP64 extension. The exception being Archive Utility for Mac.

[SqrTT]

thanks for info, I'll check if ours platform also support ZIP64

[SqrTT]

@thejoshwolfe
thanks for the input, I've checked and it works like charm
thank you.