Issue with fs.readFileand fs.unlink

[SteveyPugs]

Version: v0.12.14
Platform: Windows 7 x64
Subsystem: N/A

I am trying to read files and remove them using chokidar and async.

The issue that happens that once every couple of files I get these errors

error:  Error: EBUSY, open 'FILENAME'
    at Error (native)

{ [Error: EBUSY, unlink 'FILENAME']
  errno: -4082,
  code: 'EBUSY',
  path: 'FILENAME' }

Here is short breakdown of my code

chokidar.watch("FOLDERNAME",{
    persistent: true
}).on("add", function(filepath){
    queue.push(filepath, function(err, results){
        if(err) logger.error(err);
        fs.unlink(filepath, function(err){
            if(err) console.error(err);
        });
    });
});

var queue = async.queue(function(filepath, callback){
    fs.readFile(filepath, function(err, fileData){
        // blah process
    });
}, 1);

Any insight or direction would be helpful. Thanks!

P.S. - I am not sure I opened the issue correctly regarding the guidelines so I apologize ahead of time.

P.P.S. - nodejs/node#7368

[addaleax]

fwiw, EBUSY usually means that the file you are trying to remove is currently in use when trying to remove it.

[SteveyPugs]

@addaleax I know what the issue mostly is, the question is why it happens in v0.12.14 and it does not happen in future versions? It shouldn't happen because I am doing all of the files synchronously, or so I think in this case.

[addaleax]

@SteveyPugs You could try checking out different newer Node.js versions to find out when the bug was fixed (if I understand you correctly), that might give you an indicator of how to work around it.

Only few bugfixes are still applied to the v0.x release lines, and support for them will run out later this year, so you may want to look into upgrading anyway.

[SteveyPugs]

@addaleax this is the response I had gotten in the IRC chat with a few people. We are moving at least to v4 (LTS) at this point.

[Knighton910]

Here are a few links to get you rolling in the right direction to solve this ->

paulmillr/chokidar#325
https://github.com/isaacs/node-graceful-fs
nodejs/node-v0.x-archive#3006

-stackoverflow- Just tossing a note in here for reference: Using a try/catch fixed my problem with this error message. try { var name = fs.statSync(path); } -- it just ignores it if the file cannot be read for whatever reason, and moves on. Node has really helped me understand the value of error handling in JS. – Adrian Dec 4 '13 at 5:16

also, experiment with the drain method in async
http://www.sebastianseilund.com/nodejs-async-in-practice

ps: I don't have any expericene with older version of node on windows :) But I'm an avid googler :) cheers
If my comment wasn't helpful, add reaction downward thumb 👎 , & i'll remove it.

[SteveyPugs]

Thanks @lordKnighton

I reviewed your links. The issue is not so much the handling of the errors, I went ahead and did that more graciously now.

I've upgraded our servers up to v4.4.7, so I will see if this is resolved in the latest 4.

I will take a look at gracefuljs as well

[SteveyPugs]

@lordKnighton I am still having the issue.

I am handling it gracefully but I want to know if there is a way to prevent windows from doing this. The issue is because files that need to be read are being skipped over if locked before the read and being left behind if locked on the unlink. If my watch only loops once when it's added then I'm stuck with files not being processed.

---

Another note. I may have mistakenly put it above but the OS is actually Windows Server 2008

---

So I looked a little deeper into chokidar, I noticed at part called awaitWriteFinish. This might be the issue I have causing it. Going to try this and report back

https://github.com/paulmillr/chokidar#performance

[Knighton910]

I'm kinda of busy today, but i have looked into older documentation on this subject, but not much to start with. Hopefully later, i'll report back with something helpful, until then best of luck.

[SteveyPugs]

Thanks @lordKnighton will let you know

[Knighton910]

Using chokidar module

So what if we try:

watcher.add(['new-file-2', 'new-file-3', '**/other-file*']) ```

// followed by

.on('unlink', path => log(`File ${path} has been removed`)) 

then

// Stop watching.
watcher.close();

if not that, I'd like you to deploy breakers on your code. to see where this issue is coming from

---

what you can do, is scale down your problem, with maybe 3 files, & test it, multiple times. Then you should see, what's happening in the scheme of things.

---

On the awaitWriteFinish He is stating: The appropriate duration setting is heavily dependent on the OS and hardware

he go on to say: Use with caution

But I don't think this is exactly the problem, because this is with one file, but you're having trouble with multiple files.

[Knighton910]

I know these may seem like a stupid insertion: But on isaacs/graceful module:
It states
On Windows, it retries renaming a file for up to one second if EACCESS or EPERM error occurs, likely because antivirus software has locked the directory. you do have your antivirus off, during this process correct?