Repository navigation
Inconsistent behavior with fs module accross platforms #17801
Copy link
Copy link
Closed
Labels
fsIssues and PRs related to file-system APIs and the fs module.Issues and PRs related to file-system APIs and the fs module.help wantedIssues that need assistance from volunteers or PRs that need help to proceed.Issues that need assistance from volunteers or PRs that need help to proceed.windowsIssues and PRs related to the Windows platform.Issues and PRs related to the Windows platform.
Description
Activity
Thanks for reporting this issue!
So
require('fs').wrtieFileSync('test/', 'smth');
- on Windows creates file
testwithsmthinside, - on Linux it fails with
Error: EISDIR: illegal operation on a directory, open 'test/'
Yep, this looks like a bug for me.
@nodejs/fs
Reacted by Tuan Anh Tran and Haider Ali- on Windows creates file
- addedfsIssues and PRs related to file-system APIs and the fs module.Issues and PRs related to file-system APIs and the fs module.windowsIssues and PRs related to the Windows platform.Issues and PRs related to the Windows platform.
on Dec 21, 2017 @bzoz I don't know if am looking at the right place, But after looking at this line commet https://github.com/libuv/libuv/blob/2b32e77bb6f41e2786168ec0f32d1f0fcc78071b/src/win/fs.c#L519
atlibuvwindows implementation it seem the same code is used to access files and directories.
So I fixed it in the JS implementation, I have made a PR.Reacted by Bartosz Sosnowski- added a commit that references this issue
on Jan 11, 2018 - addedhelp wantedIssues that need assistance from volunteers or PRs that need help to proceed.Issues that need assistance from volunteers or PRs that need help to proceed.
on Jun 10, 2020 1 remaining item
- added a commit that references this issue
on Oct 10, 2024 - added a commit that references this issue
on Nov 2, 2024 Reopening because of #55527
- added 2 commits that reference this issue
on Nov 5, 2024 @StefanStojanovic Was this closed as a wont-fix? I didn't find any PR that implements this after #55527 reverted #54160. I recently got a vuln that the root cause was this inconsistency (GHSA-93m4-6634-74q7). I wonder if this inconsistency should be written in the docs.
Metadata
Metadata
Assignees
Labels
fsIssues and PRs related to file-system APIs and the fs module.Issues and PRs related to file-system APIs and the fs module.help wantedIssues that need assistance from volunteers or PRs that need help to proceed.Issues that need assistance from volunteers or PRs that need help to proceed.windowsIssues and PRs related to the Windows platform.Issues and PRs related to the Windows platform.
In Windows, if a file name ends with forward slash (
/),fsinterprets it as regular file (like there is no slash at all) and does not throw any errors. In Linux, it throws errorIMO, fs should either throw the same error in Windows, or don't throw the error in Linux.
Of course, when we talk about file name consistency, there will always be some characters which are allowed in Linux, but not allowed in Windows (like
\u0001), but that inconsistency is a result of the way OS handles these situations. However, if a file name ends with a forward slash, it either means that someone mistakenly tried to open directory as a file, or just have forgotten to remove the slash. Therefore,fsshould be consistent with the way it handles forward slash at the end of the file name. It means: either throw error always, or behave like there is no slash.I made a script which shows how it currently works.