ディレクトリからかなりの数の大きなファイルを削除する必要がありました。「rm *」を使用してファイルを削除し、別の画面に移動して別の作業を行いました。しばらくして、同じディレクトリで 'rm * ' を使用しましたが、既に使用していたことを忘れていました。
「rm: `filename' を削除できません: そのようなファイルまたはディレクトリはありません」というエラーが表示されました。次に、最初のウィンドウに移動すると、同様のエラーが発生しました。
画面はどちらが最初に rm を終了したかを競っていますか? または、サーバーは何らかの方法でプロセスをスレッド化しますか? サーバーが同じディレクトリで同じコマンドを実行すると、サーバーの画面はどのように連携しますか?
いずれの場合も、rming はファイルごとにディレクトリ エントリのリンクを解除しているだけです。2 つのプロセスは互いに競合していますが、1 つのプロセスから別のプロセスへのコンテキスト スイッチによってのみ「スレッド化」されている可能性があります。ファイルのリンクを解除する準備をしてからコンテキストを切り替えた場合、競合他社は同じファイルのリンクを解除する機会を得る可能性があります。次に、最初の人が戻ると、ファイルはもうそこにないので、そこにある次のエントリに移動します。
16 進数が言うように、この場合 ( rm *)、アスタリスクは既にファイルのリストに展開されています。つまり、2 つのプロセス間で、削除したいすべてのファイルが既になくなっている完全なリストを取得する必要があります。
問題は、同じコマンドを実行することではありません。実際、重大なことは何も起こりませんでした。rm指定したファイルが見つからない場合、コマンドはエラーで終了します。filemask (*) を指定すると、rm はそのマスクに一致するディレクトリ内のすべてのファイルの削除を開始します。最初に、プロセスはディレクトリ内のファイルのリストを取得し、次にこのリストを取得して、各ファイルの削除を個別に実行します。起動する2番目のrmプロセスはまったく同じです。ファイルのリストを取得し、それらを 1 つずつ削除し始めます。また、最初のプロセスが 2 番目のプロセスのリストにあるファイルを削除する場合があります。2 番目のプロセス fetch がそのファイル (既に削除されている) を削除しようとすると、「そのようなファイルまたはディレクトリはありません」というエラーが発生し、rm が終了します。