「rm -rf」でディレクトリを削除しようとしたが、空ではないというメッセージが表示される
「rm -rf」を使用してディレクトリを削除しようとしましたが、「ディレクトリが空ではありません」というメッセージが表示されます。
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
_そのディレクトリ内の非表示の暗号化ファイルまたは暗号化キーファイルを確認します。これらが原因である可能性があります。
ディスクユーティリティを使用してディスクを修復すると、この問題は解決しました。
私のために働いた唯一の解決策は https://unix.stackexchange.com/questions/234876/unable-to-delete-a-file-whatever-i-do からのものでした：
それらを/ tmpに移動して再起動します。
私が試した他のオプションは：
- ディスクユーティリティ-応急処置。
lsof +D bad_fileは出力を表示しませんでした。- 須藤rm -rf
- シングルユーザー端末と
rm -rf。
これが発生し、すべてを削除してもよい場合は、Sudo rm -rf directory/を使用してみてください。
私はまさにこのエラーに遭遇しましたが、ディレクトリを削除しようとしました（rm -r dirname）。このスレッドを検索して見つける前に、ここで読んだすべての提案をすでに試しました。元の質問から意図せずに述べられていない追加の点があったかどうかはわかりませんが、私の場合、問題の根源であり、解決策は次のとおりでした。
問題のディレクトリはネットワークにマウントされたディスク上にありました
finderまたはコマンドラインから
lsを試みても、.と..しか表示されませんでしたsshコマンドを使用してネットワークディスクサーバーにログインし、ls -alを確認しました。結果は、.および..に加えて、拡張セキュリティ情報（つまり、モードに.__filenameが追加された）を持ついくつかの+アイテムを示しました。
これらは、cp -R、tar、またはcpioを使用してファイルのグループをアーカイブまたは移動するときにMac OSXが数年前に作成したことに最初に気付いたファイルであるか、または類似していると思います。移動後にいくつかのファイルプロパティを適切にリセットするためにそれらが使用されたと私は推測していました-おそらくuid/gid、mode、acls、mtime/utime/ctimeなど。 notがあったプロパティは、その前にこれらのコマンドによって正しくリセットされていました（OSXにはmvmacとcpmacが含まれていたことを覚えています）これらの.__filenameタイプのファイルが、cp、tarなどの通常の形式を使用して表示される前に問題を回避するコマンド。
これらのファイルが内部、USB、またはFirewireドライブに書き込まれたときに、これらのファイルを削除するときに問題が発生したことはありませんでした。私がネットワークディスクで見つけたのはこれが初めてでした。マウントのクライアント側からは完全に検出できませんが、サーバー側から見るとすべての点で正常です。
rm -rf dirnameネットワークディスクサーバーへのログインから、ディレクトリとその内容を適切に削除しました。
したがって、その価値について別の答えがあります。この問題の別の解決策として考えられるのは、ネットワークディスクを使用している人に問題が発生した場合です。
ここですべての回答を試しましたが、結果はありませんでした。ただし、mvコマンドを使用してディレクトリを脇に移動できたため、続行できました。
読者のために：
このような場合はrm -rfに注意してください！ネットワーク共有が発生した場合、他の場所で問題が発生する可能性があります！ 警告されました！
ほとんどすべての場合、directoryが空のようであれば、rmdir directoryまたはSudo rmdir directoryを使用します。 rm（またはWindowsではdel）を使用しないでください。これが機能しない場合は、このリクエストをブロックしているものを見つけて修正し、rmdirを再試行する必要があります。
OS-Xはわかりませんが、Unix/BSDの動作とよく似ていると思います。
問題のディレクトリがマウントポイント（encfsから）であるか、読み取り専用になった、または不適切な状態でスタックしたマウントポイントにある（ディレクトリを削除できなかった）可能性が非常に高い。ディレクトリを強制的に削除すると、非常に悪いことが起こります。
良いケースでは、ディレクトリは本当に空だったので、それを削除しても（マウントの破壊など）、それ以上の害はありませんでした。最悪の場合、それは空ではなく、単に現れたように見えます。つまり、おそらく殺したくないものをゴミ箱に捨てました。これはすべて、マウントタイプ、使用中のドライバなどによって異なります。
物事が合理的にうまく実装されている場合、通常、悪いことは何も起こりません。ただし、これは通常のケースではありません。物事はすでに奇妙な状態にあります。つまり、何かがおかしいので、さらに混ぜないようにしてください。何かにひびが入った場合、間違ったタッチはそれを壊す可能性があります。
たとえば、ネットワーク共有で競合状態が発生した場合、rm -rfが他の誰かによって共有にコピーされたばかりのデータを削除する可能性があります。
ただし、rmdirは、本当に空のディレクトリを削除する以外に、害を及ぼさないことが保証されています。 NFSはmkdirとrmdirでの真のアトミック動作のみを保証し、他の場所では保証しないため、これはNFSでも当てはまります。
ご参考までに：
mountpoint directoryツールを使用して、マウントポイントを検出できます。または、mountの出力を調べて、マウントを見つけてみてください。ただし、少なくともLinuxでは、これは嘘かもしれません。 mountpointユーティリティを使用すると、信頼性は向上しますが、利便性は低下します。
その場合、マウントポイントを見つけたら、それをアンマウントしてからディレクトリを削除できます。これは次のシーケンスです。
umount directory rmdir directory
必要に応じて、通常どおりSudoを使用します。
ノート：
ネットワーク共有は、アクセス権のために
rmdir（およびその他すべて）を拒否する場合があります。欠陥戦略によっては、ファイルシステムの欠陥が
rmdirを拒否する場合があります。おそらくその場合、おそらくそうではない、妥当なメッセージが表示されます。Linux（およびおそらく現在のOS）では、さまざまな手段（読み取り専用のもののマウント、SeLinuxのような機能など）を使用してアクセスを制限することもできます。これは、それがマウントポイントであることがわからないこと、および何も問題がないことを意味しますが、機能しません。その場合は、他の理由を探す必要があり、OSに非常に深く埋め込まれている可能性があります。適切なエラーメッセージが表示されるかどうかは、ツールによって異なります。 Linuxの
dmesgのようなsyslog/kernel-logも調べてみてください（申し訳ありませんが、OS-Xでの同等の機能はわかりません）。必須のファイルロックもソースになる可能性があることに注意してください。これはWindowsでは正常ですが、通常はUnixの通常のケースではなく、ディレクトリで聞いたことはありません。必須のファイルロックはPOSIXでカバーされていますが、オプションです。
このような場合はかなり頻繁に、問題のディレクトリはあなたが思っていたのとは異なるファイルシステムに存在します。コマンド
df directory（OS-Xでもこれは同じだと思います）を使用して、どちらであるかを確認できます。ディレクトリの
statまたはstatfsなどのツールを使用して、より詳細に検査できます。ただし、これらは通常のユーザーにとっては少し低レベルであり、そのようなツールは通常のユーザーからはよく隠されています。ディレクトリには、おかしな名前のファイルを含めることができます。端末の出力をすぐに消去するファイルのように、そこにないように見えます。
ls -al | lessなどを試すか、MidnightCommandermcなどを使用してください。
バグ、ハクソール、エイリアン、またはおそらく妖精のようなよりエキゾチックなものを含む、他の可能性の訓練負荷があります。しかし、通常、そこから探し始めるのは賢明ではありません。代わりに、最初に自分の側でエラーを見つけてください。
これは、壊れたシンボリックリンクがサーバー側にあり、CIFS経由でクライアントに表示されなかったという解決策の可能性もあります。シンボリックリンクは空ではないディレクトリを作成しましたが、クライアントは、ディレクトリのリンクを解除する前にディレクトリをクリアする目的でシンボリックリンクを表示または統計できませんでした。それは目に見えないので、このパラドックスを作成しました。このパラドックスは、クライアント側からは空でしたが、rmによるチャレンジ時に「空ではありません」でした。サーバーにSSHアクセスできる場合は、その側でシェルを試して、ディレクトリが本当に空かどうか、またはシンボリックリンクが壊れていないかどうかを確認します。 Drobo5Nでこれを行うことができ、お尻を節約できました。
Windowsからそのディレクトリを開こうとすると、Mac OSに表示されないものがある可能性があります。 MacとWin PCの間でいくつかのコピー操作を行った後、同様の問題が発生しました。ターミナルでもディレクトリが空でしたが、Windowsでは非表示のWindowsファイルが見つかったため、そこからディレクトリを正常に削除しました。
アプリケーションが使用していたフォルダを削除しようとしたときにこの問題が発生しました。アプリケーションを閉じたところ、このエラーをスローせずにフォルダーを削除できたので、それを使用している可能性のあるアプリケーションを終了してみてください。
ターミナルで：
Sudo suと入力します（コマンドラインプロンプトはsh-3.2#のようなものに切り替える必要があります。）- 削除するフォルダの親フォルダに移動します
rm -rf TheDirectoryYouWantToDeleteを入力してください
同じ問題がありました。
別のMacOSボリュームまたはディスクで起動することで解決しました。次に：
Sudo rm -rf /Volume/volumewithproblem/directorywithproblem