rename(2)
次が呼び出されるので、mv
アトミックであると仮定するのは安全ですか?
$ mv /home/me/someDir /tmp/toBeDeleted
$ rm -rf /tmp/toBeDeleted
答え1
これmv
注文する~と呼ばれるrename
システムコール、原子性を保証します。しかし、2つの例外があります。
- ソースとターゲットが異なるファイルシステムにある場合(通常
/home
は一般的)、/tmp
ソースツリーをターゲットにコピーしてからソースツリーを削除するように機能しますrename
。mv
これは明らかに原子的ではありません。 rename
一部のNFS実装など、一部のファイルシステムはアトミックではありません。 「一般」ローカルファイルシステムでは、rename
これはアトミックです。
答え2
ディレクトリが単一のファイルシステムとしてマウントされた同じハードウェアパーティションにある場合、何かを移動することは、実際には別のパスに名前を変更することです。ただし、そうでない場合は、そこにあるすべてのファイルを読み取ってコピーする必要があるため、移動のどの部分も原子的ではありません。 Gillesが指摘したように、POSIXはこれが個々のファイルシステムの場合であることを指定します。
strace
それに加えて、チェックを使用したクイックチェックにはシステムコールがmv
使用されます(コマンドラインユーティリティと混同しないでください)。これにより、ユーザー空間の観点からディレクトリがアトミックに作成されます。次の場合、システムコールでEBUSYエラーが発生します。rename()
rename
mv
rename()
oldpath または newpath は、一部のプロセスで使用されているか(現在の作業ディレクトリ、ルートディレクトリ、または読み取り用に開いているため)、システムで使用されているディレクトリです(マウントポイントなど)。システムはこれを間違いと見なします。 (この場合はEBUSYを返す必要はありません。とにかく名前を変更するのは問題ありませんでしたが、システムがそのような場合を処理できない場合は許可されます。)
からman 2 rename
。ここで「原子性」への接続は、ディレクトリで作業している他のプロセスを中断できず、他のプロセスもそれを中断できないことです。トレースに勝つと、誤ったパス/見つからないタイプエラーが発生します。
答え3
これら2つの答えは本質的に同じことを言いますが、削除の1つの側面にのみ焦点を当てています。
シェルの作業ディレクトリが名前変更または移動されたディレクトリツリーにある場合は、続行します。バラよりそして使用実際に削除されるまでそのファイルを削除してください。したがって、シェルはさまざまな削除状態のファイルを確認するため、名前の変更/移動( 可能はい「原子」それ自体)いいえファイル内のすべてのユーザーの観点から見ると、これは原子形式の削除です。これは、最初からディレクトリツリーの外側にシェルがあったユーザーにのみ影響します。
シェルは、シェルが配置されているディレクトリに関する独自の情報を保持します。これは、一部の構成では、現在のディレクトリを物理パスを決定するために必要なディレクトリ情報チェーンを読み取る権限がないディレクトリに変更できるためです(たとえば、保護されたディレクトリへのシンボリックリンクを介して)。
POSIXは、このような動作の理由があいまいですが、次のことを指摘しています。pwd
(内蔵シェル)とcd
(シェル内蔵)。