fs: fix rmSync error messages for non-ASCII paths

[Yeaseen]

This PR fixes incorrect and inconsistent error messages produced by fs.rmSync when deletion fails, especially for directories containing non-ASCII characters. The issue affected Linux and Windows differently but shared the same root cause: paths were embedded into custom error messages while also being passed separately to ThrowErrnoException.

1. Duplicate paths in error messages (Linux, ASCII paths)

fs.rmSync constructed messages like:

std::string message = "Permission denied: " + file_path_str;
env->ThrowErrnoException(err, "rm", message.c_str(), path_c_str);

Because ThrowErrnoException automatically appends the path, this resulted in duplicated paths when directory names were ASCII-only:

err.path: /tmp/_dir_0
err.message: EACCES, Permission denied: /tmp/_dir_0 '/tmp/_dir_0'

2. Corrupted paths for non-ASCII directory names (Linux)

When the directory name contained non-ASCII characters, embedding the path into the message caused UTF-8 bytes to be misinterpreted.

Example:

err.path: /tmp/速速速_dir
err.message: EACCES, Permission denied: '/tmp/é速速_dir'

Here, the first byte of the UTF-8 sequence was interpreted as a Latin-1 character (é), corrupting the path shown in the error message.

3. Inconsistent Windows paths (?\ prefix)

On Windows, err.path could expose raw extended-length paths prefixed with \\?\\, because the platform-specific normalization logic (StringFromPath) was not applied when constructing ErrnoException.
Example:

err.path: \\?\\C:\\temp\\速速速_dir

This is inconsistent with other fs APIs used in src/api/exceptions, which strip the prefix before exposing paths to JavaScript.

This PR fixes the issue by:

• Removing path concatenation from custom error messages
• Passing the path only via the path argument to ThrowErrnoException
• Relying on Node’s standard error formatting to attach paths safely
• Applying StringFromPath in src/api/exceptions for Windows so err.path is normalized correctly

A new test has been added: test-fs-rmSync-special-char-additional-error.js to verify that:

• fs.rmSync reports the correct error code
• err.path preserves non-ASCII directory names
• err.message includes the correct path
• No path corruption or duplication occurs

@joyeecheung @anonrig Please review this when you are available.

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.73%. Comparing base (94b1f66) to head (d1368b0).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_file.cc	40.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #61233      +/-   ##
==========================================
- Coverage   91.77%   89.73%   -2.04%     
==========================================
  Files         338      675     +337     
  Lines      140064   204811   +64747     
  Branches    22045    39352   +17307     
==========================================
+ Hits       128543   183789   +55246     
- Misses      11298    13294    +1996     
- Partials      223     7728    +7505     

Files with missing lines	Coverage Δ
src/api/exceptions.cc	94.50% <100.00%> (ø)
src/node_file.cc	75.31% <40.00%> (ø)

... and 455 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[LucasmDjuiw]

8,5/10.

Ce document est clair, techniquement précis et facile à comprendre. Sa structure est fluide et explique le problème et sa solution sans détails superflus. Pour atteindre 9 ou 10, il faudrait simplifier légèrement quelques Casino Frumzi phrases ou ajouter une courte phrase de conclusion soulignant l'impact pour les utilisateurs ou les responsables de la maintenance.

[joyeecheung]

Code LGTM, though I am a bit skeptical about the tests - it may not fare well on Windows in the CI or in people's local machines to change the permission this way. Can we use other safer error paths to check it instead? Perhaps the directory not empty one?

[Yeaseen]

@joyeecheung thanks for the feedback. I agree. I updated the test case for hitting NOT A DIRECTORY error. Let's see if it passes CI.

[Yeaseen]

@joyeecheung looks good so far. The failing test on mac is unrelated to my changes. I appreciate a rerun. Thanks.

[Yeaseen]

@joyeecheung CI is green now — would appreciate your review.

[anonrig]

even though you moved this method, please use std::string_view. newfromutf8 takes additional parameters for the size of the input.

[Yeaseen]

@anonrig thanks for the suggestions. I've updated this function. let's see what CI says.

[anonrig]

you don't need to call concat. you can just concat them on C++ by copying the string using std::string(valueToCopy) + appendedValue and later call String::NewFromUtf8

[anonrig]

We already have this method:

node/src/util-inl.h

Line 344 in 94b1f66

v8::MaybeLocal<v8::Value> ToV8Value(v8::Local<v8::Context> context,

[Yeaseen]

@anonrig one thing to confirm: do you want this to use ToV8Value instead of calling String::NewFromUtf8 directly? just confirming the preferred approach.

Like, doing these steps?

getting the context first,
Local<Context> context = isolate->GetCurrentContext();

... then after c++ concatenation using std::string s; and append,

at the time of return this way

    Local<Value> v;
    if (!ToV8Value(context, s, isolate).ToLocal(&v)) return Local<String>();
    return v.As<String>();