fs.rmdir on Windows throws ENOENT instead of ENOTDIR

[saschanaz]

• Version: v9.3.0
• Platform: Windows 10
• Subsystem:

> fs.statSync("emmake")
Stats {
  dev: 3066473769,
  mode: 33206,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: undefined,
  ino: 105271641289789120,
  size: 548,
  blocks: undefined,
  atimeMs: 1515062172219.6804,
  mtimeMs: 1515062172220.681,
  ctimeMs: 1515062172220.681,
  birthtimeMs: 1496261901857.4617,
  atime: 2018-01-04T10:36:12.220Z,
  mtime: 2018-01-04T10:36:12.221Z,
  ctime: 2018-01-04T10:36:12.221Z,
  birthtime: 2017-05-31T20:18:21.857Z }
> fs.rmdirSync("emmake")
Error: ENOENT: no such file or directory, rmdir 'C:\Users\sasch\Documents\GitHub\emsdk\emscripten\incoming\emmake'
    at Object.fs.rmdirSync (fs.js:866:18)

It should throw ENOTDIR instead of ENOENT as there is an entry.

[bnoordhuis]

That error is reported by the operating system. There is not enough information for node.js/libuv to distinguish between 'path does not exist' and 'path is not a directory' without extra manual checks - but as that's prone to race conditions, libuv doesn't do that.

To summarize: it's probably a wontfix.

[tniessen]

That error is reported by the operating system. There is not enough information for node.js/libuv to distinguish between 'path does not exist' and 'path is not a directory' without extra manual checks - but as that's prone to race conditions, libuv doesn't do that.

@bnoordhuis Using RemoveDirectory instead of _wrmdir might solve this problem upstream. RemoveDirectory will cause ERROR_DIRECTORY if the path does not point to a directory, and ERROR_FILE_NOT_FOUND if the path does not exist. I might have time to open a PR upstream, unless there was a reason not to use RemoveDirectory in the first place? I am not sure how difficult the error code translation is...

By the way, according to the documentation of _wrmdir, the function should return ENOTEMPTY instead of ENOENT. This might be an implementation bug in the OS / CRT.

[bnoordhuis]

unless there was a reason not to use RemoveDirectory in the first place?

I can't find the thread again but the issue was that RemoveDirectory() didn't return ERROR_DIRECTORY but something like ERROR_INVALID_NAME. That said, maybe you and @saschanaz can check if this patch works as expected?

Details

diff --git a/deps/uv/src/win/error.c b/deps/uv/src/win/error.c
index 9b03bfef6b..1ec3d6e27f 100644
--- a/deps/uv/src/win/error.c
+++ b/deps/uv/src/win/error.c
@@ -131,7 +131,7 @@ int uv_translate_sys_error(int sys_errno) {
     case WSAENETUNREACH:                    return UV_ENETUNREACH;
     case WSAENOBUFS:                        return UV_ENOBUFS;
     case ERROR_BAD_PATHNAME:                return UV_ENOENT;
-    case ERROR_DIRECTORY:                   return UV_ENOENT;
+    case ERROR_DIRECTORY:                   return UV_ENOTDIR;
     case ERROR_FILE_NOT_FOUND:              return UV_ENOENT;
     case ERROR_INVALID_NAME:                return UV_ENOENT;
     case ERROR_INVALID_DRIVE:               return UV_ENOENT;
diff --git a/deps/uv/src/win/fs.c b/deps/uv/src/win/fs.c
index 11c7c13edd..e4e4c58d7a 100644
--- a/deps/uv/src/win/fs.c
+++ b/deps/uv/src/win/fs.c
@@ -723,8 +723,11 @@ void fs__write(uv_fs_t* req) {
 
 
 void fs__rmdir(uv_fs_t* req) {
-  int result = _wrmdir(req->file.pathw);
-  SET_REQ_RESULT(req, result);
+  if (RemoveDirectoryW(req->file.pathw)) {
+    SET_REQ_SUCCESS(req);
+  } else {
+    SET_REQ_WIN32_ERROR(req, GetLastError());
+  }
 }
 
 

[tniessen]

@bnoordhuis That's exactly what I had in mind and it seems to work as expected:

I am not sure whether this will have implications for other APIs, depending on whether Windows uses ERROR_DIRECTORY for other error conditions as well.

[bnoordhuis]

It might have been an XP-only issue or a buggy driver or something like that. Filed libuv/libuv#1698.

[bnoordhuis]

I can't find the thread again but the issue was that RemoveDirectory() didn't return ERROR_DIRECTORY but something like ERROR_INVALID_NAME.

See libuv/libuv@9f07a36, it was that it also returns ERROR_DIRECTORY when the directory is missing. Reverted upstream.

I'm leaving this closed because I'm not going to revisit it. For anyone wanting to work on this, libuv is the place where the action happens.

[saschanaz]

MSDN documents ERROR_DIRECTORY as The directory name is invalid, which doesn't say how invalid it is. Sad.