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 #56934
Open

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

kanasimi opened this issue Nov 28, 2024 · 10 comments · May be fixed by #56934
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.

@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?

@jimmywarting

This comment was marked as off-topic.

Yeaseen added a commit to Yeaseen/node that referenced this issue Feb 6, 2025
…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.\n\nAdd 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.\n\nFixes: nodejs#56049
Yeaseen added a commit to Yeaseen/node that referenced this issue Feb 6, 2025
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 two tests 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
@Yeaseen Yeaseen linked a pull request Feb 6, 2025 that will close this issue
Yeaseen added a commit to Yeaseen/node that referenced this issue Feb 6, 2025
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 two tests 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
Yeaseen added a commit to Yeaseen/node that referenced this issue Feb 7, 2025
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 two tests 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
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
9 participants