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.rmSync('速') crash without throw #56049

Open
kanasimi opened this issue Nov 28, 2024 · 10 comments · May be fixed by #56117
Open

fs.rmSync('速') crash without throw #56049

kanasimi opened this issue Nov 28, 2024 · 10 comments · May be fixed by #56117
Labels
confirmed-bug Issues with confirmed bugs. fs Issues and PRs related to the fs subsystem / file system. good first issue Issues that are suitable for first-time contributors. windows Issues and PRs related to the Windows platform.

Comments

@kanasimi
Copy link

Version

23.3.0

Platform

Windows 10

Subsystem

No response

What steps will reproduce the bug?

When fs.rmSync('速') files with name containing “速”, node 23.3.0 will crash without throw.

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

Everytime

What is the expected behavior? Why is that the expected behavior?

Delete the file normally.

What do you see instead?

The program just crashed.

Additional information

There are other special characters that can cause similar problems, such as “請”. This problem did not occur in previous versions.

@lpinca lpinca added the fs Issues and PRs related to the fs subsystem / file system. label Nov 28, 2024
@islandryu
Copy link
Contributor

It might be related to #55773.

@kanasimi
Copy link
Author

v22.11.0 is OK, but v23.0.0 also has problems.

@joyeecheung
Copy link
Member

This seems, once again, a problem from using std::filesystem::path on Windows, and wasn't taken care of as part of #55015 (cc @anonrig who authored #53617). See #53063 (comment) on an explanation about this class of bugs.

(With the amount of crashes reported for this bug on Windows, I start to feel that we might as well should just forbid std::filesystem::path in the code base unless it's absolutely justified, as it's so easy to miss the encoding inconsistency on Windows.....)

@anonrig
Copy link
Member

anonrig commented Nov 29, 2024

I recommend forbidding std::filesystem::path as well. It's not worth it.

@jazelly jazelly added the windows Issues and PRs related to the Windows platform. label Nov 30, 2024
@joyeecheung joyeecheung added confirmed-bug Issues with confirmed bugs. good first issue Issues that are suitable for first-time contributors. labels Dec 2, 2024
@joyeecheung
Copy link
Member

joyeecheung commented Dec 2, 2024

It seems no one is working on it yet, so marking it as good first issue. See #53063 (comment) on how this sort of bug happens and how they can be fixed. In this case I believe one just needs to change

node/src/node_file.cc

Lines 1629 to 1630 in 56e5bd8

env, permission::PermissionScope::kFileSystemWrite, path.ToStringView());
auto file_path = std::filesystem::path(path.ToStringView());

To use ToU8StringView() instead, since the call was actually changed to use std::filesystem calls, which only takes std::filesystem::paths.

@geeksilva97
Copy link
Contributor

I will give it a try

@Yeaseen
Copy link

Yeaseen commented Dec 3, 2024

@geeksilva97 I would like to try this if you haven't done it yet. I started building with the suggested change and will write the test to check. This would be my first contribution here. Thank you.

Yeaseen added a commit to Yeaseen/node that referenced this issue Dec 3, 2024
Update fs.rmSync to properly handle file paths that include non-ASCII
characters. This change prevents crashes and errors when attempting to
delete files with international or special characters in their names.

Add a test in test/parallel to ensure that files with non-ASCII characters
can be deleted without issues, covering cases that previously led to
unexpected behavior or crashes on certain file systems.

Fixes: nodejs#56049
@Yeaseen Yeaseen linked a pull request Dec 3, 2024 that will close this issue
@geeksilva97
Copy link
Contributor

@geeksilva97 I would like to try this if you haven't done it yet. I started building with the suggested change and will write the test to check. This would be my first contribution here. Thank you.

Of course. Go for it.

@kanasimi
Copy link
Author

kanasimi commented Dec 3, 2024

Do we need to do an extensive check to see if there are other places with similar problems?

Yeaseen added a commit to Yeaseen/node that referenced this issue Dec 5, 2024
Update fs.rmSync to properly handle file paths that include
non-ASCII characters. This change prevents crashes and errors
when attempting to delete files with international or special
characters in their names.

Add a test in test/parallel to ensure that files with non-ASCII
characters can be deleted without issues. This covers cases
that previously caused unexpected behavior or crashes on
certain file systems.

Fixes: nodejs#56049
@jimmywarting

This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed-bug Issues with confirmed bugs. fs Issues and PRs related to the fs subsystem / file system. good first issue Issues that are suitable for first-time contributors. windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants