Evan Oxfeld

Thanks, @timsweb. I believe I'm having the same problem with the inflater stream - the readable side of that stream awaits a drain event that's never emitted. The stream instances...

Just to update everyone I haven't been able to reproduce the error with a pullstream test case. Perhaps the issue is with writing data greater than the zlib stream's highWaterMark...

After resolving nearinfinity/node-pullstream#6 without resolving this `unzip` issue, I'm more confident that the problem results from last minute changes to Transform streams in 0.10. I'll troubleshoot some more today, and...

Also perhaps this issue is related to joyent/node#5051. I still need to confirm, though.

The commit in node that created this issue is related to Transforms streams, not zlib - joyent/node@e26622bd18fc86033cea393125cad49c577b524b. While I'd like a resolution on why the zlib inflateRaw stream stalls and...

@satazor I'm working on this issue this morning, using node 0.10.2, and trying to isolate the problem to `node-unzip`, `node-pullstream` or `node` itself. I could use some help building a...

@richtera Thanks for DirWriter stack trace. Although unzip.Parse() fails and does not use the fstream dependency, perhaps there's an issue with fstream as well.

Likely unzip.Parse doesn't complete because the entry streams emitted by unzip.Parse need to be consumed by being piped or having read() called on them, otherwise they exert backpressure upstream. Interestingly,...

A fix for unzip.Parse is coming soon, then I'll look into the recursive process.nextTick calls causing unzip.Extract to blow up.

Made the below updates that should resolve the unzip.Parse issues. Thanks to @wanderview for the suggestion. - If you never register an `on('entry')` listener, unzip.Parse consumes and throws away the...