プロセスの移動許可が拒否された場合、mv
はcp(1)
として機能しますか?
もしそうなら、それはルールに反しているのではありませんか?
簡単に言えば、そうではないということです。
rename()
関数と同等のアクションを実行します
rename()
はコンテンツをコピーせず、単にディスク上の名前を変更します。これは完全にアトミックな操作であり、部分的に完全に失敗することはありません。
しかし、それだけでは全体像はわかりません。この効果が発生する可能性があるのはデバイス間でファイルを移動しようとしたときです。その場合、ファイルシステムで名前の変更を行うことはできません。移動の効果を得るには、mv
は最初にソースを宛先にコピーし、次にソースを削除します。事実上、mv /mnt/a/X /mnt/b/Y
は本質的にcp /mnt/a/X /mnt/b/Y && rm /mnt/a/X
と同等です。これが、デバイス間でファイルを移動する唯一の方法です。
mv
にそのソースファイルを削除する権限がない場合、エラーが報告されますが、その時点でコピーはすでに発生しています。操作中にパーミッションが変更される可能性のある競合状態のため、事前にパーミッションを確認してそれを回避することはできません。
デバイス間でファイルを移動することをまったく不可能にする以外に、この起こり得る不測の事態を防ぐ方法は実際にはありません。任意のソースと宛先の間でmv
を許可するという選択は、これらの異常なケースでの奇妙な(しかし非破壊的な)動作を犠牲にして、一般的なケースで物事を単純にします。
これは、単一のデバイス内で大きなファイルを移動する方が、別のデバイスに移動するよりもはるかに高速である理由でもあります。