Repository navigation
ENOENT thrown when trying to create a file with an invalid filename #8987
Description
Activity
Pretty sure that error codes comes straight from the Windows API, and it even seems consistent with macOS, so I'd lean towards leaving it as-is. Doing a check for filename validity on Windows is costly and should probably be done by the user.
Reacted by Nathan Phillip BrinkPretty sure that error codes comes straight from the Windows API
Are you sure? I tried the equivalent in C#:
File.WriteAllText("c:\\temp\\foo:bar:baz", "winning");And got a better error message:
System.NotSupportedException: The given path's format is not supported.Or:
System.ArgumentException: Illegal characters in path.I didn't try raw Win32 API calls though.
So, just in case this is helpful: Colons are used by NTFS to name separate Alternate Data Streams, so if there’s a file named
foo, creatingfoo:barand writing to it (as an ADS) should work.So it would seem to me that ENOENT would be the correct code for writing to
foo:barwhenfoodoesn’t exist.I’m not sure the overhead of checking for multiple colons would be worth it…
Reacted by Nathan Phillip BrinkI believe it might be technically possible to provide a better error message since
CreateFileW()on Windows probably sets the 'last error' code toERROR_BAD_PATHNAMEin such cases. From what I can tell, the original Windows-specific error code is stored by libuv in such a way that node should have access to it.Reacted by Daniel Lo Nigro, Nathan Phillip Brink and Sindre SorhusSo it would seem to me that ENOENT would be the correct code for writing to foo:bar when foo doesn’t exist.
Interesting, I didn't know that.
The same error message happens for other invalid characters though, such as question marks:
> fs.writeFileSync('C:\\temp\\foo??', 'fail') Error: ENOENT: no such file or directory, open 'C:\temp\foo??' at Error (native) at Object.fs.openSync (fs.js:640:18) at Object.fs.writeFileSync (fs.js:1333:33) at repl:1:4The issue here is that libuv maps
ERROR_INVALID_NAMEtoUV_ENOENThere. This particular mapping was added by @piscisaureus way back in 2012.The question is what it should map to instead. Would
UV_EINVALbe better? Understandably, libuv doesn't have a dedicated error code for an invalid file name since Linux doesn't have invalid filenames.You could change it (major version), but before you do so, do some research into what different "libc" implementations do on windows - at least try what error the open() call in msvcrt produces when you try to create a file with an invalid name, and try cygwin too.
Linux doesn't have invalid filenames.
A
/is a invalid character in a filename on all likely all Linux filesystems. The returned error code depends on the location of the/in the filename:fs.writeFile("invalid/") // Error: EISDIR: illegal operation on a directory, open 'invalid/' > fs.writeFile("invalid/file") // Error: ENOENT: no such file or directory, open 'invalid/file'Good idea. I assume you meant fopen, not open.
fopen("foo??", "w")setserrnotoEINVALin both CRT and MSYS2.In both of your examples,
/is interpreted as a path separator. I don't think it's even possible to make Linux interpret it as part of the file name.Reacted by Nathan Phillip BrinkThanks for reporting this issue, I had no idea that : were invalid file name characters in Windows, been debugging an Electron app for a bit now.
- added a commit that references this issue
on May 31, 2017 Should this issue remain open?
It's going to remain an issue until libuv is upgraded to 2.x.
- added a commit that references this issue
on Jul 20, 2019 There's been no activity on this and it's been blocked indefinitely pending the update to libuv 2.x. Keeping the issue open does not benefit anyone but we also don't want to forget about it. I've added it to a Futures project board so it doesn't get lost.
Node v6.7.0, Windows 10
To reproduce the issue:
Expected output: Some error message about the filename being invalid because it contains colons
Actual output: