Handle win32 er.code equivalents to "EMFILE" #19

wants to merge 1 commit into


None yet
3 participants

isaacs commented Jul 26, 2013

Neither of these are the equivalent of EMFILE. They don't indicate that there are too many files open, and backing off is not the right way to handle them. So, I'm closing this pull request. However, I AM curious about how you're finding yourself in this state!

If the error code is "OK", then something is very wrong. That's a bug in Node.

How are you getting EBUSY?

@isaacs isaacs closed this Jul 26, 2013

See this function. This is what we have been doing in the past. A simple function that copies file from one dest to another.

But, on win32 there is an issue: when copying ~1000+ files with that function, it starts throwing this “OK”.

What we’re doing now is this. Basically an input or output (readStream / writeStream) emits error event with the error.

@es128 es128 deleted the es128:patch-1 branch Jul 26, 2013

es128 commented Jul 26, 2013

The queuing there does work pretty well on the OK, open errors. It looks pretty similar to how graceful-fs is doing it, except using setImmediate to execute the queued tasks, which cut down on overlapping error instances and improved performance. Btw, the full message of the UNKNOWN errors is like UNKNOWN, open #{filename} - equivalent to the OK ones except the error code part, and the solution works equally well there. Performance is pretty good when you go a little bit over the limit, but seems to get exponentially worse as the file count increases to points substantially above the limit.

EBUSY happens when I copy a lot of files into the directory being watched using windows explorer. The watcher, in turn, is trying to copy them into another directory. The solution I wrote so far isn't solving this case because it doesn't build up the initial block of successful copy operations which trigger the queue as they finish.

es128 commented Jul 26, 2013

Also, in case this is helpful, the UNKNOWN errors show up occasionally after a long trail of OK errors. Like, just one or two of them sometimes right after hundreds or thousands of OKs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment