nodejs / nodejs/node

fs: rmSync() reports UV_UNKNOWN with an empty code for unmapped errno values

オープン
#65,884 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
JavaScript
スター
122k
フォーク
37.3k
平均マージ
4日 2時間
マージ済み PR(30日)
283

説明

Version

v26.7.0

Platform

Linux x64

Subsystem

fs / src/node_file.cc

What steps will reproduce the bug?
const fs = require('node:fs');
fs.mkdirSync('a/b', { recursive: true });
try {
  fs.rmSync('a/.', { recursive: true, force: true });
} catch (err) {
  console.log('code   :', JSON.stringify(err.code));
  console.log('errno  :', err.errno);
  console.log('syscall:', err.syscall);
  console.log('message:', err.message);
}

Output:

code   : ""
errno  : -4094
syscall: "rm"
message: , Unknown error: Invalid argument 'a/.'
What is the expected behavior? Why is that the expected behavior?

err.code should be 'EINVAL' and err.errno should be -22. The underlying
failure is a plain EINVAL from rmdir(2), which POSIX requires for a path whose
final component is ..

Every other fs error carries a usable code, and err.code === 'EINVAL' is the
documented way to branch on fs failures, so an empty string breaks ordinary error
handling. The message is also malformed: it begins with , because the empty code
is interpolated into it.

What do you see instead?

errno is -4094 (UV_UNKNOWN) and code is the empty string.

Additional information

This is not specific to EINVAL. RmSync() in src/node_file.cc translates the
std::error_code from std::filesystem::remove_all() with a hardcoded chain that
covers four values:

  • operation_not_permitted -> EPERM
  • directory_not_empty -> ENOTEMPTY
  • not_a_directory -> ENOTDIR
  • permission_denied -> EACCES (EPERM on Windows)

Anything else falls through to the tail of the function:

std::string message = "Unknown error: " + error.message();
return env->ThrowErrnoException(
    UV_UNKNOWN, "rm", message.c_str(), path_c_str);

So the mapping is an allowlist rather than a translation, and any errno outside
those four surfaces as UV_UNKNOWN with an empty code. EINVAL is simply the
one that is easiest to trigger from user code.

The async form is unaffected, because fs.rm() and fsPromises.rm() use the JS
rimraf and report EINVAL correctly.

Noting for context that the dot segment handling in #61958 is being addressed
separately at the JS layer. That change stops a/. from reaching this code path,
but it does not fix the mapping, which stays reachable for other errnos.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

src/node_file.cc の RmSync() を読み、std::filesystem::remove_all() の std::error_code がどのように Node.js エラーになるかを追跡します。EINVAL のようなマッピングされていない errno に対する回帰テストのカバレッジを追加し、返される code、errno、message が、空の code を持つ UV_UNKNOWN ではなく使用可能であることを検証します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
cpp, javascript, nodejs
領域
operating-systems
issue の種類
バグ
難易度
3/5
見積もり時間
1〜2日
活発さ
活発
明瞭さ
明確に書かれている
初心者へのやさしさ
76/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。