Finished event called too soon

[0x80]

After unzipping I immediatly traverse the directory structure with walk. The last few directories that were unzipped are always missed on the content traversal. If I trigger the same code on an already unzipped directory it finds all content.

To me it looks like the "finished" event is called prematurely. I've tested this on node 0.10 0.12 and iojs 1.5 and all give the same behavior.

Or is this expected behavior and should I somehow work around it? I've now solved it by simply making the excution wait a little while before doing the walk but that is a hack of course, and not very reliable at all.

[binarybro]

I have the same issue as the previous poster.

I had a quick look at the source code, and it seems that the parser's flush-callback is called, after emitting the 'close' event. It works for me if I change...

Parse.prototype._flush = function (callback) {
  if (!this._streamEnd || !this._streamFinish) {
    return setImmediate(this._flush.bind(this, callback));
  }

  this.emit('close');
  return callback();
};

...to...

Parse.prototype._flush = function (callback) {
  if (!this._streamEnd || !this._streamFinish) {
    return setImmediate(this._flush.bind(this, callback));
  }

  var r = callback();
  this.emit('close');
  return r;
};

[0x80]

Good find 👍 If it's just a callback I expect there's no point returning the result from it. Likely the original return was just a tail call.

Haven't tried it to be honest, but it would come down to

Parse.prototype._flush = function (callback) {
  if (!this._streamEnd || !this._streamFinish) {
    return setImmediate(this._flush.bind(this, callback));
  }

  callback();
  this.emit('close');
};

[joswhite]

I had the same issue. Except that my problem was that my unzip.Extract handler was on the finish event. When I changed the handler to the close event, it worked just fine. (I should have looked more closely at the examples in the test code!) My zip file is only 160kB, so I guess it wasn't large enough to be affected by the order-of-execution problem mentioned by @dzire187.

[leontastic]

I also encountered this issue. Calling fs.readFile on any newly extracted file in the finish event handler consistently results in an ENOENT: no such file or directory error. This doesn't happen if you use the close event.