link(link_target, hardlink_tmp); rename(hardlink_tmp, hardlink);私のコードは常に有効なdentryを持つことを目指して同様のことをしていますhardlink。私はそれが動作し続け、dentries決して遅れないことを願っていますhardlink_tmp。
ところで、今日残っているhardlink_tmpファイルがたくさん見つかりました。検索rename(2)結果：
If oldpath and newpath are existing hard links referring to the same file, then rename() does nothing, and returns a success status.
次のフレーズが少し異なりますrename(3p)。
If the old argument and the new argument resolve to either the same existing directory entry or different directory entries for the same existing file, rename() shall return successfully and perform no other action.
unlink(hardlink_tmp);これで、古い可能性のあるディレクトリエントリを最後に削除する必要があります。
これが望ましい行動であるのはなぜですか？
ベストアンサー1
両方の名前を同じファイルに変更するためのPOSIX仕様にも制限があります。「理由」セクションには次のように記載されています。:
古いファイルと新しいファイルが同じファイルを参照する場合、仕様は次のことを保証します。
rename("x", "x");ファイルは削除されません。
これはやや単純ですが、理論的根拠でrename()+に代わるものも言及したことを考えると、次のようになります。 link()unlink()——純粋に推測です——簡単な実装はrename(x, y)で実装できますunlink(y) && link(x, y) && unlink(x)。ただし、との名前xがy同じ場合、最初のステップでファイルが消えます。
rename("../foo/x", "x")また、両方の名前がまったく同じ文字列であることを確認するだけでは不十分です。これは、似たような状況（座っているときfoo/）や悪い状況rename("/dir/symlink/x", "x")（シンボリックリンクのために戻ってきた場合.）が発生する可能性があるためです。両方の文字列の結果が同じファイル名であることを確認するのは簡単ではありませんが、両方の文字列をstat()呼び出してデバイスとinode番号を確認して同じinodeであることを確認する方が簡単です。その後、2つのファイル名が異なりますが、同じファイルであっても名前の変更を拒否します。
rename()これは、予想通り、最新のスマート実装がより良いパフォーマンスを発揮できないという意味ではありませんが、「常に機能する方法」に基づいてコーディングされている可能性があります。 （推測終了）