要約

  • draft-ietf-nfsv4-internationalization-17 は、NFSv4の名前が不透明なオクテット列として比較される場合と、Unicode、正規化、大小文字を意識して扱われる場合を整理する。クライアントが一度の成功から完全な等価規則を知ることはできない。
  • バックアップ、複製、切り替え、移行の前には「名前空間等価性レシート」を作り、入力バイト、返された名前、環境、衝突試験、能力情報、未確認事項を一つの証拠として残すべきだ。

見つかった理由は一つではない

画面上では同じ文字列に見えても、Unicodeでは異なる並びで表現できることがある。アクセント付きの一文字を合成済みの符号位置で表す方法と、基底文字と結合文字に分ける方法が典型だ。人間に同じ名前でも、プロトコルが運ぶバイトは同じとは限らない。

その両方で同じファイルが開いたとしても、分かるのはサーバーが今回の問い合わせを受理したことだけだ。NFS実装が正規化したのか、下位のファイルシステムが等価比較したのか、保存時に書き換えたのか、検索時だけ別表記を認めたのかは、成功応答だけでは決まらない。反対に、一方が失敗しても、Unicodeそのものが「非対応」だと単純化することはできない。

NFSv4国際化ドラフトの第17版は、2026年9月11日に提出された。IETF Last Call後のコメントを反映した版で、Standards Trackの活発なInternet-DraftとしてIESGに提出されている。まだRFCではなく、特定製品への実装を示す資料でもない。

この文書の重要な点は、実装の歩みを出発点にしていることだ。シェパード報告によると、NFSv4.1に書かれた国際化の仕組みは想定どおりには実装されなかった。列挙された主要実装では、NFSv4.0型のUTF-8非認識の扱いが広く使われ、Unicodeを認識する機能は限定的または実験的だった。規範文が現実を作ったと仮定せず、実際に相互接続してきた振る舞いから境界を引き直している。

バイト列を名前とする世界

UTF-8を認識しないファイルシステムでは、名前の各要素は不透明なバイト列だ。比較はオクテット単位で行われる。古い文字コードで作られた名前や、有効なUTF-8ではない並びを保持できる一方、Unicode上で正規等価な二つの表現を同一と扱う根拠はない。

これは欠陥というより、原バイトに権限を与える一貫した方針である。Unicodeライブラリーが更新されても、既存の二項目が勝手に一つになる心配は小さい。しかし入力方式やアプリケーションが別の正規形を生成すれば、利用者には同じに見える名前で検索が失敗しうる。

UTF-8を認識する側には複数の設計がある。保存前に所定の正規形へ写像することも、受け取った表記を保存しつつ検索時に正規等価を認めることもできる。大小文字についても、写像する方式と比較時に同一視する方式がある。どの層がその判断を担うかも一定しない。サーバー、下位ファイルシステム、設定の組み合わせが実効的な方針になる。

国際化された大小文字の扱いは、言語や利用者の選好にも関係する。ドラフトは、それらを一般的に通知する仕組みはまだ標準化できる段階にないとする。「Unicode対応」という一語では、受理、保存、比較のどれを意味するかすら分からない。

fs_charset_capが答えられる範囲

fs_charset_cap属性には意味があるが、範囲は狭い。現行案では、サーバーがUTF-8のファイル名だけを受け入れることを示す。過去のFSCHARSET_CAP4_CONTAINS_NON_UTF8は意味が明確でなく、サーバーにはその補集合を提供すること、クライアントには同フラグを無視することが勧告されている。属性が未対応なら、非UTF-8名を使った管理下の試験で受理条件の一部を調べられる。

それでも、正規化の有無、Unicodeの版、大小文字の完全な等価集合は見えない。UTF-8だけを受け付けることと、二つのUTF-8名を同じと判断することは別の契約だ。能力ビットから等価関数を推定してはならない。

成功例を増やしても事情は同じである。十回のLOOKUPは十個の観測点であり、規則そのものではない。Unicodeの追加文字、言語固有の大小文字、ストレージ固有の例外が未試験なら、結論にもその空白を残さなければならない。

READDIRは別名一覧ではない

ディレクトリーをすべて読めば名前空間が分かる、という考えも十分ではない。サーバーは保存した一つの表記をREADDIRで返しながら、LOOKUPでは正規等価な別表記を受け入れられる。列挙結果は表示名の集合であって、各ファイルに到達できる質問の集合ではない。

クライアントのキャッシュには実害が出る。クライアント自身の等価規則で「存在しない」を記憶すると、サーバーなら認めた別表記まで負の結果で覆いかねない。READDIRに局所比較で一致する名前がないためLOOKUPを省略すれば、サーバーが返せた対象を見逃すこともある。ドラフトが、正規化に備えつつ実施を前提にしないよう求めるのは、この観測不能性のためだ。

時間も名前の意味に入る。Unicodeに新しい文字が追加されると、正規等価クラスに構成員が加わる場合がある。長く残るファイル名に一つの保存正規形を強制するより、形式に依存しない比較が好まれる理由の一つである。同じバイトを保存していても、更新後の環境が新しい関係を認める可能性は残る。

移行では裁定者が交代する

通常の移行試験は、ファイル数、容量、時刻、権限、ハッシュを比べる。どれも必要だが、名前の等価性は別の対象である。移行先に項目を作ると、受け付け可能なバイトと同一視する表記について、新しい裁定が行われる。

移行元が区別した二名を移行先が統合すれば衝突する。移行元が統合した表記を移行先が区別すれば、アプリケーションが長年使った別表記から届かなくなる。移行先が非UTF-8の履歴名を拒めば、内容は保存できても元のアドレスは保存できない。大小文字方針の変更では、別々だったパスが競合する。

よく使うファイルを数件開く試験は、危険な名前をほとんど選ばない。現在のキーボードやライブラリーが作りやすい名前に偏るからだ。古いシステムが残したバイト、珍しい結合列、かつてサーバーが黙って吸収していた差異は対象外になりやすい。

バックアップは復元時まで欠陥を隠し、その時には原本が消えているかもしれない。複製は一項目を静かに統合しても成功に見える。切り替えでは、内容のある待機系へアプリケーションだけが到達できない事態になる。

名前空間等価性レシート

境界を越える前に、観測した意味を持ち運ぶ短い証拠が必要だ。ここでは「名前空間等価性レシート」と呼ぶ。IETFドラフトの要件ではなく、運用判断を後から検証できるようにする提案である。

まずNFS版、サーバー製品と版、判明している下位ファイルシステム、エクスポートとマウントの設定、OS、Unicodeライブラリー、試験日時を記録する。名称は安全な表示と正確なバイト列の両方で保存する。人が読む表記だけでは、証拠を保存する道具自身が正規化してしまう恐れがある。

試験集合は実在する名称から作り、組織の言語環境に合った合成形・分解形、大小文字、既存の非UTF-8列、版差の影響を受けうる文字を加える。作成や衝突試験は隔離領域で非破壊的に行う。各形のLOOKUPが同じfilehandleを返すか、READDIRが何を表示するか、作成が拒否されるか、fs_charset_capが何を示すか、負キャッシュを除いた結果はどうかを残す。

同じ試験を移行元と移行先で行い、観測、ベンダー説明、未検証の推定を別欄にする。衝突、拒否、曖昧な結果には担当者と処置を割り当てる。可逆的な改名、エスケープ、隔離、互換層、影響を理解した例外承認のいずれかである。変換するなら、原バイト、移行先名、内容識別子の対応表を原本廃止後も残す。

対象範囲は広げすぎない。シンボリックリンクの内容は別種の不透明列であり、非ASCIIドメイン名はU-labelの規則に従う。NFSの文字列型は全部同じではない。レシートが証明するのは、特定環境で試した特定の関係だけだ。

証明できること、できないこと

RFC 6943は、識別子比較の不整合が誤一致、見落とし、サービス拒否、場合によっては権限昇格につながると説明する。これはNFSの実被害を報告するものではなく、このドラフトも事故を主張していない。しかしパスが認可、実行、保存記録に関わるなら、名前比較を安全性の審査に入れる十分な理由になる。

確実に言えるのはここまでだ。ある時点のサーバー側名前空間が、その時の挙動で、提出されたバイト列を一つの対象へ解決した。文字の普遍的な同一性も、別のエクスポート、クライアント、バックアップ、移行先が同じ判断をすることも証明していない。検索成功は局所的事実であり、移植性は境界ごとに作る証拠である。

参考資料