「rm -rf」でディレクトリを削除しようとしましたが、空ではないというメッセージが表示されました

「rm -rf」を使用してディレクトリを削除しようとしましたが、「Directory not empty」というメッセージが表示されます。

Bens-MacBook-Pro:please benjaminhocking$ ls -lart empty_directory/
total 16
drwxr-xr-x  5 benjaminhocking  staff  170 Aug 27 14:46 .
drwxr-xr-x  3 benjaminhocking  staff  102 Aug 27 15:28 ..
Bens-MacBook-Pro:please benjaminhocking$ rm -rf empty_directory/
rm: empty_directory/: Directory not empty
Bens-MacBook-Pro:please benjaminhocking$ rmdir empty_directory/
rmdir: empty_directory/: Directory not empty

Finderを使用して同じこと（フォルダをゴミ箱にドラッグ）を試みると、メッセージが表示されます

アイテム「empty_directory」が使用中のため、操作を完了できません。

私はxattr -d com.apple.quarantine純粋に迷信からやってみましたが、うまくいきませんでした。

おそらく重要なコンテキストは、このディレクトリが最初に、ターミナルがロックアップする前に発行した「make clean」コマンドによって削除されるべきディレクトリにあったことです。その後、他のプログラムの半分強がまた、Skype、最終的にはOS自体も含めて、実行がロックされます。電源キーを押したままにして、コンピューターを再起動しなければならなくなりました。

編集して追加：続けたもう1つの重要な情報は、これが暗号化されたフォルダーアラで発生したことencfsです。暗号化されたものの対応するフォルダーを追跡し、そこで削除することができました。普段のように、解読された側からできない理由はまだわかりません。誰かがそれに対する良い答えを持っている場合に備えて、今のところこれを未回答のままにします。

コンピューターを再起動して、rmdir(1)もう一度実行してください。

$ rmdir -r empty_directory/

それがうまくいかない場合は、試してください：

$ rm -rf empty_directory/

それでも動作しない場合は、OS Xがlsof(8)プレインストールされていると仮定して、次のように入力します。

$ lsof +D empty_directory/

これにより、このディレクトリ内のファイルがプログラムで使用されているかどうかがわかります。HFS +ファイルシステムでは、使用中のファイルを削除できないと思います。とにかく、killall(1)このディレクトリまたはその中の隠しファイルを使用している可能性のある実行可能ファイル。Finderがempty_directoryディレクトリ内の隠しファイルを使用してフォルダビュー設定を保存している可能性があります。お役に立てれば。

PS：lsof(8)インストールされているかどうかを確認するには、次のように入力します。

$ lsof

出力が次のようになっている場合はlsof(8)、システムにインストールされています。

lsof: /usr/bin/lsof /usr/bin/X11/lsof /usr/share/man/man8/lsof.8.gz

そのディレクトリ内の非表示および暗号化ファイルまたは暗号化キーファイルを確認します。これらが犯人である可能性があります。

ディスクユーティリティを使用してディスクを修復すると、この問題は解決しました。

これが発生し、すべてを削除したい場合は、使用してみてください sudo rm -rf directory/

ディレクトリを削除しようとしたときに、まさにこのエラーに遭遇しました（rm -r dirname）。このスレッドを検索して見つける前に、ここで読んだ提案をすべて試しました。元の質問から意図せずに追加のポイントが残っている可能性があるかどうかはわかりませんが、私の場合はトラブルの根源であり、解決策は次のとおりでした：

• 問題のディレクトリがネットワークマウントされたディスク上にあった

• 任意のlsFinderやコマンドラインからの試みは何も示さなかったが、.と..

• sshコマンドを使用してネットワークディスクサーバーにログインし、ls -alそこで確認しました。結果は、.およびに加えて、セキュリティ情報が拡張された（つまり、モードに追加された）..いくつかの.__filename項目を示しました+。

私はこれらがあると考えている、または私が最初に使用するときに年前に作成マックOSX指摘したファイルと類似しているcp -R、tarまたはcpioファイルのアーカイブや移動のグループには。移動後にいくつかのファイルプロパティを適切にリセットするためにそれらが使用されたとき、私は推測していました-おそらくuid / gid、mode、acls、mtime / utime / ctimeなど。私は本当にわからない-いた性質ではないという時間の前に、これらのコマンドによって正しくリセットを取得しては、（私はOSXを含めるために使用されることを覚えておくmvmacと、cpmacこれらの前のコマンドの問題を回避するには.__filename、ファイルの種類は通常のフォームを使用しているとき現れ始めcp、tarなど）。

これらのファイルが内部ドライブ、USBドライブ、またはFirewireドライブに書き込まれたときに、これらのファイルを削除する際に問題が発生したことはありませんでした。ネットワークディスクでそれらを見つけたのはこれが初めてでした。マウントのクライアント側からは完全に検出できませんが、サーバー側から見るとあらゆる点で正常です。

rm -rf dirname ネットワークディスクサーバーのログインから、ディレクトリとその内容を適切に削除しました。

そのため、価値があるものには別の答えがあります。ネットワークディスクに関連するすべてのユーザーにこの問題が発生する場合、この問題に対する別の潜在的なソリューション

ここですべての回答を試みましたが、結果はありませんでした。ただし、mvコマンドを使用してディレクトリを移動することができたため、続行できました。

私のために働いた唯一の解決策はhttps://unix.stackexchange.com/questions/234876/unable-to-delete-a-file-whatever-i-doからのものでした：

それらを/ tmpに移動して再起動します。

私が試した他のオプションは次のとおりです。

• ディスクユーティリティ-応急処置。
• lsof +D bad_file 出力が表示されませんでした。
• sudo rm -rf
• シングルユーザー端末とを起動しますrm -rf。

読者の利益のために：

rm -rfそのような場合には注意してください！ ネットワーク共有である場合、他の場所で問題が発生する可能性があります！ 警告されました！

ほぼすべてのケースでは、場合directory、空のようです、使用しrmdir directory多分かsudo rmdir directory。rm（またはdelWindowsで）使用しないでください。これが機能しない場合は、このリクエストをブロックしているものを見つけて修正し、再試行する必要がありますrmdir。

私はOS-Xを知らないことに注意してください。しかし、そこにあるものはUnix / BSDの動作に非常に似ていると思います。

これは、問題のディレクトリがちょうどだった可能性が非常に高いマウントポイント（encfsから）または読み取り専用になりましたか（削除するディレクトリを防ぐ）いくつかの不適切な状態のままマウントポイントに常駐しています。ディレクトリを強制的に削除すると、非常に悪いことが起こる可能性があります。

良いケースでは、ディレクトリは本当に空だったので、それを削除（マウントを破壊するなど）してもそれ以上の害はありませんでした。悪いケースでは、それは空ではなく、ただあるように見えました。つまり、あなたはおそらく殺したくない何かをゴミ箱に捨てました。これはすべてマウントタイプ、使用中のドライバーなどに依存します。

物事が合理的にうまく実装されていれば、通常は何も悪いことは起こりません。ただし、これは通常のケースではありません。物事はすでに奇妙な状態にあります。つまり、何かがおかしいので、さらに混同しないでください。何かが割れた場合、間違ったタッチで破損する可能性があります。

たとえば、ネットワーク共有で競合状態になった場合、rm -rf他の誰かによって共有にコピーされたばかりのデータが削除される可能性があります。

ただしrmdir、本当に空のディレクトリを削除する以外に、決して害を及ぼさないことが保証されています。NFSだけに、本当にアトミック動作を保証ので、これは、NFS上でさえ真実であるmkdirとrmdir、しかし、どこにも。

参考までに：

ツールを使用してマウントポイントを検出できますmountpoint directory。または、の出力を調べて、mountマウントを見つけようとします。しかし、少なくともLinuxではこれは嘘をつくかもしれないことに注意してください。mountpointユーティリティを使用すると、信頼性は向上しますが、利便性は低下します。

その場合、マウントポイントが見つかった場合は、マウントポイントをアンマウントしてからディレクトリを削除できます。これは次のシーケンスです。

umount directory rmdir directory

必要に応じてsudo、通常どおりを使用します。

ノート：

• ネットワーク共有はrmdir、アクセス権が原因で拒否（およびその他のもの）する場合があります。

• rmdir障害戦略によっては、ファイルシステムの欠陥により拒否される場合があります。その場合、おそらくあなたは合理的なメッセージを見るでしょう。

• Linux（およびおそらく最新のOS）では、さまざまな手段（読み取り専用のマウント、SeLinuxのような機能など）を使用してアクセスを制限することもできます。これは、マウントポイントであることがわからないことを意味します。また、何も間違っていることはありませんが、機能しません。その場合、他の理由を探す必要があり、OSに深く埋もれてしまう可能性があります。妥当なエラーメッセージが表示される場合は、ツールによって異なります。また、おそらくdmesgLinuxのようにsyslog / kernel-logを確認してください（OS-Xに相当するものは知りません）。

• 強制的なファイルロックもソースになる可能性があることに注意してください。これはWindowsでは正常ですが、通常はUnixの場合は正常ではなく、ディレクトリについては聞いたことがありません。必須のファイルロックはPOSIXでカバーされていますが、オプションです。

• そのような場合、かなり頻繁に、問題のディレクトリは、あなたが思ったのとは異なるファイルシステムに存在します。あなたはコマンドでこれを見つけることができますdf directory（これはOS-Xでも同じだと思います）。

• ディレクトリなどのツールをstat使用statfsして、さらに詳しく調べることができます。しかし、これらは普通の人には少し低いレベルであり、そのようなツールは普通のユーザーからはかなり隠されています。

• ディレクトリは、面白い名前のファイルを持つことができます。すぐに端末の出力を消去するファイルのように、そこにないように見えます。ls -al | lessMidnightCommanderのようなものを試すか、使用しますmc。

バグ、ハクサー、エイリアン、またはおそらく妖精のようなよりエキゾチックなものを含む、他の可能性の列車があります。しかし、通常、そこを探し始めるのは賢明ではありません。代わりに、「人為的エラー」のため、まずあなたの側でエラーを見つけようとします。

これは、壊れたシンボリックリンクがサーバー側にあり、CIFSを介してクライアントに表示されないという、解決したばかりの場合もあります。シンボリックリンクは空ではないディレクトリに読み込まれましたが、ディレクトリのリンクを解除する前にディレクトリをクリアする目的でクライアントがシンボリックリンクを表示または統計できませんでした。それは目に見えないので、クライアント側からはrmによるチャレンジ時に「空ではない」がクライアント側からこのパラドックスを作成しました。サーバーへのSSHアクセスがある場合は、その側でシェルを試して、ディレクトリが本当に空であるか、シンボリックリンクが壊れているかどうかを確認します。Drobo5Nでこれを行うことができたので、助かりました。

Windowsからそのディレクトリを開いてみてください。MacOSには表示されないものがあります。MacとWindows PCの間で多くのコピー操作を行った後、同様の問題が発生しました。ターミナルでもディレクトリは空でしたが、Windowsでは非表示のWindowsファイルが見つかったため、そこからディレクトリを削除しました。

ターミナルで：

1. Enter sudo su （コマンドラインプロンプトはのようなものに切り替わりsh-3.2#ます）
2. 削除するものの親フォルダーに移動します
3. 入る rm -rf TheDirectoryYouWantToDelete

アプリケーションが使用しているフォルダーを削除しようとしたときに、この問題が発生しました。アプリケーションを閉じると、このエラーをスローせずにフォルダーを削除できるため、使用している可能性のあるアプリケーションを終了してみてください。