Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fs.mkdirSync on windows make something wrong #35987

Closed
ruhuansanmei opened this issue Nov 6, 2020 · 7 comments
Closed

fs.mkdirSync on windows make something wrong #35987

ruhuansanmei opened this issue Nov 6, 2020 · 7 comments

Comments

@ruhuansanmei
Copy link

  • Version:
  • Platform: windows 10
  • Subsystem:

What steps will reproduce the bug?

     let path = "./abc::abc"
    fs.mkdirSync(path, {
      recursive: true
    })
   the code above made system busy but no err can be caught,I think it is because of that windows doesn't allow use some symbol as directroy name!But I think there should be errors thrown.

How often does it reproduce? Is there a required condition?

What is the expected behavior?

What do you see instead?

Additional information

@ruhuansanmei
Copy link
Author

let path = "资料架标准:-外观统一,保持干净整洁、无灰尘、无破损" ,making the problem too.

@mmomtchev
Copy link
Contributor

mmomtchev commented Nov 6, 2020

In that particular case, Windows will return an ERROR_DIRECTORY:

case ERROR_DIRECTORY: return UV_ENOENT;

On Windows, libuv doesn't make a difference between ENOENT and ENOTDIR - something that has been by now deeply embedded in all the unit tests and the user code base.

And this is what MKDirpSync uses to break the endless loop:

case UV_ENOTDIR:

The right decision would be to make that bold move and correctly translate the Windows error codes?
Or push an ugly hack into MKDirpSync?
Or let someone come with a brilliant idea?

@mmomtchev
Copy link
Contributor

In fact, this mapping has been made on a purpose in Node v0.8.19:
https://nodejs.org/en/blog/release/v0.8.19/
And has already been discussed here
#18014

@mmomtchev
Copy link
Contributor

#27207

@mmomtchev
Copy link
Contributor

/cc @richardlau
This issue is slightly different from the one from the previous fix

CreateDirectoryW returns ERROR_DIRECTORY which is not an official return code per MS doc https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createdirectoryw

uv_mkdir returns ENOENT for the first level and EEXISTS and ISDIR for the base level - making it look completely normal without any indication that this name cannot be created

My suggestion will be to fix it in libuv this time with a custom error mapping for mkdir just like that one:

if (req->sys_errno_ == ERROR_INVALID_NAME)

@richardlau
Copy link
Member

@mmomtchev Since this is in libuv code it should be discussed over in https://github.com/libuv/libuv. I think this issue is the same/similar to #31177? In which case there's an open PR to change the mapping of ERROR_INVALID_NAME: libuv/libuv#2601

cc @nodejs/platform-windows

@ruhuansanmei
Copy link
Author

Thanks!Who commented under this give me a new way to think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants