rename(2)
は によって呼び出されるのでmv
、以下はアトミックであると想定しても安全でしょうか?
$ mv /home/me/someDir /tmp/toBeDeleted
$ rm -rf /tmp/toBeDeleted
答え1
のmv
指示呼び出しrename
システムコールこれはアトミックであることが保証されています。ただし、例外が 2 つあります。
- ソースと宛先が異なるファイルシステム上にある場合 (これは
/home
vs.では比較的一般的です/tmp
)、はrename
失敗し、mv
ソース ツリーを宛先にコピーしてからソース ツリーを削除することで機能します。これは明らかにアトミックではありません。 rename
NFS の特定の実装など、 がアトミックではないファイルシステムもあります。任意の「通常の」ローカル ファイルシステムでは、rename
はアトミックです。
答え2
ディレクトリが同じハードウェアパーティション上にあり、単一のファイルシステムとしてマウントされている場合、何かを移動するということは、実際には単に別のパスに名前を変更するということである。しかし、そうでない場合は、内部の各ファイルを読み込んでコピーする必要があるかもしれないので、移動のどの部分もアトミックではない。Gilles が指摘するように、POSIX は、これは個別のファイルシステムの場合に当てはまると規定している。
それ以外では、 による簡単なチェックで、がシステム コールを使用していることがstrace
確認できます(コマンド ライン ユーティリティの と混同しないでください)。これにより、ディレクトリに対する の実行がユーザー空間の観点からアトミックになります。システム コールは、次の場合に EBUSY エラーをスローします。mv
rename()
rename
mv
rename()
oldpath または newpath は、何らかのプロセスによって使用されているディレクトリ (現在の作業ディレクトリ、ルート ディレクトリ、または読み取り用に開かれているためなど)、またはシステムによって使用されているディレクトリ (マウント ポイントなど) ですが、システムはこれをエラーと見なします。(このような場合、EBUSY を返す必要はありません。名前の変更を行うことには何の問題もありませんが、システムがそのような状況を処理できない場合は、EBUSY を返すことができます。)
からman 2 rename
。ここでの「原子性」との関連は、ディレクトリで作業中の別のプロセスを中断できず、別のプロセスがこれを中断できないことです。追跡でそれを打ち負かすと、無効なパス/見つからないタイプのエラーが発生します。
答え3
どちらの回答も本質的には同じことを言っていますが、削除の 1 つの側面にのみ焦点を当てています。
名前を変更/移動したディレクトリツリー内に作業ディレクトリがあるシェルの場合は、引き続き見るそして使用これらのファイルは実際に削除されるまでは、シェルはさまざまな削除状態にあるファイルを認識し、その結果、名前の変更/移動( 5月なれ「原子」それ自体はないファイルのすべてのユーザーの観点から見ると、削除のアトミック形式です。これは、最初からディレクトリ ツリーの外側にシェルがあるユーザーにのみ影響します。
シェルは、自分がどのディレクトリにいるかに関する独自の情報を保持しています。これは、構成によっては、保護されたディレクトリへのシンボリック リンクをたどるなどして、実際のパスを決定するために必要なディレクトリ情報のチェーンを読み取る権限がないディレクトリに現在のディレクトリを変更する可能性があるためです。