☰

ディレクトリシンボリックリンクの末尾のスラッシュ

tag-icon • tag-icon directory filenames symlink coreutils
ディレクトリシンボリックリンクの末尾のスラッシュ

私はUNIX系システムでパス検証プロセスをエミュレートしようとしています（manページpath_solutionを参照）。

私のオペレーティングシステムは、GNU coreutils 8.7がインストールされているLinuxです。

回避策では、追加の末尾の「/」の意味を明確にするために、シェルで次のことを行いました。

mkdir this_is_dir
ln -s this_is_dir this_is_link
rm this_is_link

this_is_linkはシンボリックリンクですが、ちょうど削除したので、すべてが大丈夫です。しかし試してみると：

mkdir this_is_dir
ln -s this_is_dir this_is_link
rm this_is_link/

鳴り響いたrm: cannot remove 'this_is_link/': Is a directory

まあ、末尾の「/」によってシンボリックリンクがついてくるようです。だから別のコマンドを試しました。rmdir this_is_link/

興味深い結果が出ました：rmdir: failed to remove 'this_is_link/': Not a directory

私が期待していたものとは異なります。だから私は友人に自分のシステムでも同じ結果が得られることを確認するように頼んだ。彼のcoreutilsバージョンは私のバージョンより低いです。そしてその結果はすごいですね、rmまたは、関係なくrmdir 'this_is_link/'同じエラーが発生します。Not a directory。

他の友人がMac OSで試してみたところ、結果は次のとおりです。rm=> 'ディレクトリです'、rmdir=>ディレクトリが正常に削除され、リンクが保持されます。。

関連仕様がありますか？精密パスチェック動作？

答え1

これPOSIX/シングル Unix 仕様末尾のスラッシュで指定されたパス名はディレクトリを参照する必要があります（参照：基本定義§4.11パス名の確認）。実際には（ファイル名を操作するときではなくパス解決の目的で使用され、末尾のスラッシュは無視されます）foo/と同じように定義されます。ほとんどの実装ではこれを尊重しますが、いくつかの例外があります。foo/.basenamedirname

これは動作を説明します。引数は明らかにディレクトリrm this_is_link/と同じです。rm this_is_link/.

rmdir this_is_link/ディレクトリも同様に参照する必要があります。コンピュータにこの機能がないことはGNU coreutilsのバグです。 OSXはここで正常に動作します。

答え2

私の視点では：

  • 「rm link /」は、rmが最後の文字を見てそれがスラッシュであることを確認し、あなたが見る（実際には正確ではない）診断を提供するので失敗します。
  • 「rmdir link /」失敗：リンクはディレクトリではなくシンボリックリンクです。
  • 「rm link」は正しく成功します。

ちなみに、パスチェックはこれとは何の関係もありません。ただ、「rm」が引数に対して（正確に）「stat」を呼び出すのではなく（rmdirが実行するアクション）ショートカットを使用するようです。

乾杯。

関連情報