Mencoba menghapus direktori dengan "rm -rf", tetapi dapatkan pesan bahwa itu tidak kosong

Saya sudah mencoba menghapus direktori menggunakan "rm -rf" dan saya menerima pesan "Direktori tidak kosong":

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

Jika saya mencoba hal yang sama menggunakan Finder (menyeret folder ke Sampah), saya mendapatkan pesan

Operasi tidak dapat diselesaikan karena item "empty_directory" sedang digunakan.

Saya sudah mencoba melakukan xattr -d com.apple.quarantine, murni karena takhayul, tetapi tidak ada gunanya.

Bagian konteks yang mungkin penting adalah bahwa direktori ini awalnya berada di direktori yang seharusnya sudah dihapus oleh perintah "bersihkan" yang saya keluarkan sebelum Terminal mengunci saya, setelah itu sedikit lebih dari setengah dari program lain yang saya punya berjalan juga terkunci, termasuk Skype, dan akhirnya OS itu sendiri. Saya akhirnya harus me-reboot komputer dengan menekan dan menahan tombol daya.

Sunting untuk ditambahkan: Sepotong informasi penting lain yang saya tinggalkan adalah bahwa ini terjadi di folder terenkripsi à la encfs. Saya dapat melacak folder yang sesuai di sisi terenkripsi hal dan menghapusnya di sana. Saya masih tidak tahu mengapa saya tidak bisa melakukannya dari sisi dekripsi seperti yang biasa saya lakukan. Saya akan meninggalkan ini tidak terjawab untuk saat ini jika ada yang punya jawaban yang baik untuk itu.

Nyalakan kembali komputer Anda dan jalankan rmdir(1)kembali.

$ rmdir -r empty_directory/

Jika itu tidak berhasil, cobalah:

$ rm -rf empty_directory/

Jika masih tidak berfungsi, anggap OS X telah lsof(8)diinstal sebelumnya, lalu masukkan:

$ lsof +D empty_directory/

Ini akan memberi tahu jika ada file dalam direktori ini yang digunakan oleh program apa pun. Saya pikir sistem file HFS + tidak memungkinkan penghapusan file yang digunakan. Bagaimanapun, killall(1)setiap executable yang mungkin menggunakan direktori ini atau file tersembunyi apa pun di dalamnya. Kemungkinan Finder menggunakan file tersembunyi di empty_directorydirektori untuk menyimpan pengaturan tampilan folder. Semoga ini membantu.

PS: Untuk mengetahui apakah lsof(8)sudah diinstal, masukkan:

$ lsof

Jika outputnya terlihat seperti ini, maka lsof(8)diinstal pada sistem Anda.

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

Periksa apakah ada file tersembunyi dan terenkripsi atau file kunci enkripsi dalam direktori itu. Ini bisa menjadi pelakunya.

Memperbaiki disk menggunakan Disk Utility memperbaiki masalah ini untuk saya.

Jika ini terjadi dan Anda yakin ingin menghapus semuanya, Anda harus mencoba menggunakan sudo rm -rf directory/

Saya mengalami kesalahan ini tepat ketika juga mencoba untuk menghapus direktori (rm -r dirname). Saya sudah mencoba semua saran yang saya baca di sini sebelum mencari dan menemukan utas ini. Saya tidak tahu apakah mungkin ada poin tambahan yang tidak sengaja tidak dinyatakan dari pertanyaan awal, tetapi dalam kasus saya, akar masalahnya, dan solusinya adalah:

• direktori yang dimaksud adalah pada disk yang terpasang di jaringan

• lsupaya apa pun dari Finder atau baris perintah hanya menunjukkan .dan..

• Saya masuk ke server disk jaringan melalui sshperintah dan memeriksa di ls -alsana. Hasilnya menunjukkan, selain .dan .., beberapa .__filenameitem dengan informasi keamanan tambahan (yaitu, +ditambahkan ke mode).

Saya percaya ini, atau mirip dengan, file yang pertama kali saya mencatat Mac OSX menciptakan tahun yang lalu ketika menggunakan cp -R, taratau cpiountuk arsip atau memindahkan kelompok file. Saya telah menyimpulkan pada saat itu bahwa mereka digunakan untuk mereset dengan benar beberapa properti file setelah pindah - mungkin uid / gid, mode, acls, mtime / utime / ctime, dll; Saya tidak benar-benar yakin - properti yang belum direset dengan benar oleh perintah-perintah sebelum waktu itu (saya ingat bahwa OSX digunakan untuk memasukkan mvmacdan cpmacperintah untuk mengatasi masalah sebelum .__filenamejenis file ini mulai muncul ketika menggunakan bentuk biasa cp, tar, dll).

Saya tidak pernah menemui masalah menghapus file-file ini ketika mereka telah ditulis ke drive internal, USB, atau Firewire; ini adalah pertama kalinya saya menemukan mereka di disk jaringan; benar-benar tidak dapat terdeteksi dari sisi klien mount, tetapi normal dalam segala hal bila dilihat dari sisi server.

rm -rf dirname dari login di server disk jaringan dengan benar menghapus direktori beserta isinya.

Jadi, ada jawaban lain untuk apa nilainya; solusi potensial lain untuk masalah ini jika muncul untuk siapa saja bersama dengan disk jaringan.

Sudah mencoba semua jawaban di sini tanpa hasil. Namun, saya dapat memindahkan direktori ke samping menggunakan perintah mv , yang memungkinkan saya untuk melanjutkan.

Satu-satunya solusi yang bekerja untuk saya adalah dari https://unix.stackexchange.com/questions/234876/unable-to-delete-a-file-whthing-i-do :

Pindahkan ke / tmp dan mulai ulang.

Opsi lain yang saya coba adalah:

• Disk Utility - Pertolongan Pertama.
• lsof +D bad_file tidak menunjukkan output.
• sudo rm -rf
• Booting ke terminal pengguna tunggal dan rm -rf.

Untuk kepentingan pembaca:

Waspadalah rm -rfdalam kasus seperti itu! Itu dapat membuat masalah di tempat lain jika itu terjadi menjadi berbagi jaringan! Anda telah diperingatkan!

Dalam hampir semua kasus, jika a directorytampaknya kosong, gunakan rmdir directoryatau mungkin sudo rmdir directory. Jangan gunakan rm(atau di delbawah Windows). Jika ini tidak berhasil, Anda perlu mencari tahu, apa yang menghalangi permintaan ini, memperbaikinya dan kemudian coba lagi rmdir.

Harap dicatat bahwa saya tidak tahu OS-X, tapi saya pikir hal-hal di sana sangat mirip dengan perilaku Unix / BSD.

Sangat mungkin bahwa direktori yang dimaksud hanyalah titik mount (dari encfs) atau berada pada titik mount yang menjadi readonly atau macet dalam keadaan yang tidak tepat (yang mencegah direktori untuk dihapus). Jika sekarang Anda memaksakan penghapusan direktori, hal yang sangat buruk dapat terjadi.

Dalam kasus yang baik direktori tersebut benar-benar kosong, jadi menghapusnya (menghancurkan mount dll) tidak ada salahnya lebih lanjut. Dalam kasus buruk itu tidak kosong, hanya tampaknya, yang berarti, Anda menghancurkan sesuatu yang Anda mungkin tidak ingin membunuh. Ini semua tergantung pada tipe mount, driver mana yang digunakan dll. Hlm.

Jika semuanya dilaksanakan dengan cukup baik, biasanya tidak ada hal buruk yang akan terjadi. Namun ini bukan kasus normal. Hal-hal sudah dalam keadaan aneh, yang berarti: Ada yang salah, jadi lebih baik jangan mencoba untuk mencampurnya lebih jauh! Jika ada yang retak, sentuhan yang salah dapat merusaknya.

Misalnya, jika Anda mencapai kondisi balapan di jaringan berbagi, mungkin Anda rm -rfmenghapus data yang hanya disalin ke berbagi oleh orang lain.

Namun rmdirdijamin tidak akan membahayakan, selain menghapus direktori yang benar-benar kosong. Ini bahkan berlaku di NFS, karena NFS hanya menjamin perilaku atom yang benar-benar mkdirdan rmdir, tetapi tidak di tempat lain.

FYI:

Anda dapat mendeteksi titik mount menggunakan alat ini mountpoint directory. Atau lihat output mountdan coba tandai mount Anda di sana. Tapi waspadalah, setidaknya di Linux ini mungkin bohong. Menggunakan mountpointutilitas lebih dapat diandalkan tetapi kurang nyaman.

Jika Anda menemukan mountpoint, Anda bisa melepasnya dan kemudian menghapus direktori, ini adalah urutan berikut:

umount directory rmdir directory

Jika perlu digunakan sudo, seperti biasa.

Catatan:

• Pembagian jaringan mungkin menolak rmdir(dan hal lain) karena hak akses.

• Sistem file yang rusak dapat ditolak rmdir, tergantung pada strategi yang gagal. Mungkin Anda akan melihat pesan yang masuk akal dalam kasus itu, mungkin tidak.

• Di Linux (dan mungkin semua OS modern) Anda juga dapat membatasi akses menggunakan cara yang berbeda (seperti memasang sesuatu yang hanya bisa dibaca, kemampuan seperti di SeLinux, dll.). Ini kemudian berarti Anda tidak melihat bahwa itu adalah mountpoint, dan Anda tidak melihat sesuatu yang salah, tetapi itu tidak berfungsi. Dalam hal ini Anda perlu mencari alasan lain dan itu bisa sangat terkubur di OS. Itu tergantung pada alat jika Anda melihat beberapa pesan kesalahan yang masuk akal. Mungkin juga melihat ke syslog / kernel-log seperti dmesgdi Linux (maaf, saya tidak tahu setara OS-X).

• Perhatikan bahwa penguncian file wajib juga dapat menjadi sumber. Walaupun ini normal pada Windows, biasanya ini bukan kasus normal Unix dan saya tidak pernah mendengarnya untuk direktori. Kunci file wajib dicakup oleh POSIX, tetapi bersifat opsional.

• Cukup sering dalam kasus seperti itu, direktori tersebut berada pada sistem file yang berbeda dari yang Anda pikirkan. Anda dapat mengetahui yang mana, dengan perintah df directory(saya pikir ini sama di bawah OS-X).

• Anda dapat memeriksa lebih dalam dengan alat-alat seperti statatau statfspada direktori. Namun ini adalah level yang agak rendah untuk orang normal, dan cukup sering alat seperti itu tersembunyi dengan baik dari pengguna normal.

• Direktori dapat memiliki file dengan nama lucu. Seperti file yang segera menghapus output terminal, jadi sepertinya tidak ada di sana. Coba sesuatu seperti ls -al | lessatau gunakan sesuatu seperti MidnightCommander mc.

Ada banyak kereta kemungkinan lain, termasuk bug, haxor, alien, atau mungkin hal-hal yang lebih eksotis seperti peri. Tetapi biasanya tidak bijaksana untuk mulai mencari di sana, sebagai gantinya pertama-tama cobalah untuk menemukan kesalahan di sisi Anda, karena "errare humanum est".

Ini juga bisa menjadi kasus yang baru saja saya selesaikan di mana symlink yang rusak ada di sisi server dan tidak terlihat oleh klien melalui CIFS. Symlink mengisi direktori non-kosong, tetapi klien tidak dapat melihat atau membuat stat symlink untuk tujuan membersihkan direktori sebelum memutuskan tautan direktori. Karena itu tidak terlihat, itu menciptakan paradoks ini di mana dari sisi klien itu kosong tetapi "tidak kosong" pada tantangan oleh rm . Jika Anda memiliki akses SSH ke server, coba sebuah shell di ujung itu dan lihat apakah direktori tersebut benar-benar kosong atau apakah mungkin ada symlink yang rusak. Saya bisa melakukan ini pada Drobo5N dan itu menyelamatkan saya.

Cobalah untuk membuka direktori itu dari Windows, mungkin ada sesuatu yang tidak ditampilkan di Mac OS. Saya memiliki masalah serupa setelah sejumlah operasi penyalinan antara Mac dan Win PC: direktori itu kosong bahkan di terminal tetapi pada Windows saya menemukan file windows tersembunyi, jadi saya berhasil menghapus direktori dari sana.

Di terminal:

1. enter sudo su (Prompt baris perintah harus beralih ke sesuatu seperti sh-3.2#.)
2. arahkan ke folder induk dari yang ingin Anda hapus
3. memasukkan rm -rf TheDirectoryYouWantToDelete

Saya mengalami masalah ini ketika mencoba menghapus folder yang digunakan Aplikasi. Ketika saya menutup Aplikasi itu saya membiarkan menghapus folder tanpa membuang kesalahan ini, jadi cobalah untuk keluar dari Aplikasi yang mungkin menggunakannya.