rmdirSync returns before too early causing "operation not permitted" on next operation

[unional]

node: 9.4.0
OS: Windows Server 2016

This code causes "operation not permitted" on mkdir on every 2nd attempt

if (fs.existsSync(dir)) fs.rmdirSync(dir)
fs.mkdirSync(dir)

The callback version works fine:

return new Promise(a => {
  if (fs.existsSync(cwd)) {
    fs.rmdir(cwd, () => {
      fs.mkdir(cwd, a)
    })
  }
  else {
    fs.mkdir(cwd, a)
  }
})

[mscdex]

What's the point of removing the directory just to create it again? The directory already has to be empty to remove it. Why not just call fs.mkdirSync() in a try-catch/try-finally and only ignore EEXIST errors?

[unional]

That is just an example.
I think there is some leakage happening overall.
This could be the cause of
AvianFlu/ncp#127

[bnoordhuis]

Can you post a minimal, ready-to-run test case rather than an excerpt? The devil frequently is in the details.

[unional]

I can repro it here: https://github.com/unional/issues/tree/node-fs
It happens when I run npm run watch (running jest in watch mode).

It can very consistently reproduce the behavior. It just follows a pass -> fail -> pass -> fail pattern.

It seems like there is some sync issue between node's fs and jest watching the newly created folder.

So I don't know if it is node's related or more like jest related.

However, it is strange that the same thing does not happen in OSX. I run the same code in OSX and it is working fine.

So it might still worth investigating. 🌷

[bnoordhuis]

There's that devil. :-) You're running into a Windows quirk where file watching takes out a lock on the directory being watched. It's not specific to Node.js.

Some of the caveats are listed in the fs.watch() and fs.watchFile() documentation, which is what jest (indirectly) uses.

I'll close this out. Thanks anyway for the report.

[unional]

Thanks. Learning something new everyday. 👍

Seems like you are referring to this:
https://nodejs.org/api/fs.html#fs_fs_watchfile_filename_options_listener

Note: When a file being watched by fs.watchFile() disappears and reappears, then the previousStat reported in the second callback event (the file's reappearance) will be the same as the previousStat of the first callback event (its disappearance).

This happens when:

the file is deleted, followed by a restore
the file is renamed twice - the second time back to its original name

So for the mkdir() call, the stat still says the file exists, thus failing the operation?

However, what's strange is that the previousStat is retrieved by the mkdir(), not the watch() used by jest.

[bnoordhuis]

Hm, maybe the note was removed; it's only hinted at obliquely now.

If you google for "ReadDirectoryChanges ERROR_ACCESS_DENIED", you'll get a couple of hits that explain the issue. ReadDirectoryChanges is the operating system API that Node.js uses on Windows.