Намагаються видалити каталог з "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, а з часом і саму ОС. Мені довелося перезавантажити комп'ютер, натиснувши та утримуючи клавішу живлення.

Редагувати, щоб додати: Ще одна важлива інформація, яку я зупинила, - це те, що це відбувається в зашифрованій папці à la 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

Перевірте наявність прихованих та зашифрованих файлів або файлів ключів шифрування в цьому каталозі. Це можуть бути винуватцями.

Ремонт диска за допомогою Disk Utility вирішив цю проблему для мене.

Якщо це сталося, і ви впевнені, що хочете видалити все, спробуйте скористатися sudo rm -rf directory/

Я зіткнувся саме з цією помилкою, намагаючись також видалити каталог (rm -r dirname). Я вже спробував усі пропозиції, які я прочитав тут, перш ніж шукав і знайшов цю тему. Я не знаю, чи можуть бути якісь додаткові пункти ненавмисно залишені незрозумілими від початкового питання, але в моєму випадку корінь проблеми, і рішення було:

• відповідний каталог знаходився на мережевому диску

• будь-яка lsспроба Finder або командного рядка не показала нічого, крім .і..

• Я зайшов на сервер мережевого диска за допомогою sshкоманди і перевірив ls -alтам. Результат показав, на додаток до .та .., кілька .__filenameелементів із розширеною інформацією про безпеку (тобто +додані до режиму).

Я вважаю , що це, або схожі на файли , які я перший зазначив Mac OSX створення років тому при використанні cp -R, tarабо cpioв архів або перемістити групи файлів. На той момент я вивів, що вони використовувались для правильного скидання деяких властивостей файлів після переїзду - можливо, uid / gid, mode, acls, mtime / utime / ctime тощо; Я не дуже впевнений - властивості, які до цього часу не були правильно скинуті цими командами (я пам’ятаю, що OSX використовував для включення mvmacта cpmacкоманди для вирішення проблеми до того, як ці .__filenameтипи файлів почали з’являтися під час використання звичайних форм cp, tarтощо).

Я ніколи не стикався з видаленням цих файлів, коли вони були записані на внутрішній, USB або Firewire диск; це я вперше знайшов їх на мережевому диску; повністю невизначним з клієнтської сторони кріплення, але нормальним у всіх відношеннях при погляді з боку сервера.

rm -rf dirname з логіну на мережевому диску-сервері належним чином видалено каталог разом із його вмістом.

Отже, є ще одна відповідь на те, чого вона варта; ще одне потенційне рішення цієї проблеми, якщо воно з’явиться для когось спільно з мережевим диском.

Спробували всі відповіді тут без результатів. Проте мені вдалося перемістити каталог убік за допомогою команди mv , яка дозволила мені продовжувати.

Єдине рішення, яке працювало для мене, було з /unix/234876/unable-to-delete-a-file-wwhat-i-do :

Перемістіть їх до / tmp та перезапустіть.

Інші варіанти, які я спробував, були:

• Утиліта диска - перша допомога.
• lsof +D bad_file не показали результатів.
• sudo rm -rf
• Завантаження в однокористувацький термінал і rm -rf.

Для користі читачів:

Остерігайся rm -rfв такому випадку! Це може створити проблеми десь в іншому випадку, якщо трапиться мережева частка! Вас попередили!

Майже у всіх випадках, якщо , directoryздається, порожній, використання rmdir directoryабо можливо sudo rmdir directory. Не використовуйте rm(або delпід Windows). Якщо це не працює, вам потрібно з’ясувати, що блокує цей запит, виправити це, а потім повторити спробу rmdir.

Зауважте, що я не знаю OS-X, але я думаю, що там речі дуже схожі на поведінку Unix / BSD.

Цілком ймовірно, що цей каталог був просто точкою монтажу (з encfs) або проживанням у точці монтажу, яка перетворилася наново чи застрягла в якомусь неналежному стані (що заважало видалити каталог). Якщо тепер змусити видалити каталог, можуть статися дуже погані речі.

У хорошому випадку каталог справді був порожнім, тому видалення його (знищення кріплення тощо) не принесло більше шкоди. У поганому випадку це було не порожньо, просто виявилося, що означає, що ви потрапили в щось, чого, можливо, не хотіли вбивати. Все це залежить від типу кріплення, які драйвери використовуються тощо. Pp.

Якщо все реалізовано досить добре, зазвичай нічого поганого не повинно статися. Однак це не звичайний випадок. Речі вже в дивному стані, це означає: Щось не так, тож краще не намагайтеся ще більше перемішувати це! Якщо щось зламається, будь-яке неправильне дотик може зламати його.

Наприклад, якщо ви потрапили на стан перегонів на загальнодоступну мережу, можливо, ви rm -rfвидалите дані, які просто скопіював хтось інший.

Однак rmdirгарантовано ніколи не завдасть шкоди, окрім видалення справді порожніх каталогів. Це вірно навіть на NFS, оскільки NFS тільки гарантує дійсно елементарне поведінку на mkdirі rmdir, але ніде.

FYI:

Ви можете виявити точку кріплення за допомогою інструменту mountpoint directory. Крім того, погляньте на вихід mountта спробуйте помітити там свої кріплення. Але будьте обережні, принаймні під Linux це може лежати. Використання mountpointутиліти більш надійне, але менш зручне.

У тому випадку, коли ви знайшли точку монтування, ви можете її відключити, а потім видалити каталог, це наступна послідовність:

umount directory rmdir directory

За потреби користуйтеся sudo, як зазвичай.

Примітки:

• Мережеві акції можуть відмовити rmdir(і все що завгодно) через права доступу.

• Несправні файлові системи можуть заперечувати rmdir, залежно від стратегії відмови. Можливо, ви побачите в цьому випадку розумне повідомлення, можливо, ні.

• У Linux (і, мабуть, будь-яка сучасна ОС) ви також можете обмежувати доступ за допомогою різних засобів (наприклад, монтувати щось лише для читання, можливостей, таких як SeLinux тощо). Це означає, що ви не бачите, що це точка опори, і ви не бачите нічого поганого, але це просто не працює. У такому випадку потрібно шукати якусь іншу причину, і вона може бути дуже глибоко закопана в ОС. Це залежить від інструменту, якщо ви бачите якесь розумне повідомлення про помилку. Можливо, також загляньте в syslog / kernel-log, як dmesgу Linux (вибачте, я не знаю еквівалента OS-X).

• Зверніть увагу, що джерело може бути і обов'язковим блокуванням файлів. Хоча це нормально для Windows, зазвичай це не нормальний випадок Unix, і я ніколи не слухав його для каталогів. Обов’язкові блокування файлів покриваються POSIX, але вони не є обов'язковими.

• Досить часто в таких випадках довідник знаходиться в іншій файловій системі, ніж ви думали. Ви можете дізнатись, яка за допомогою команди df directory(я думаю, це те саме в OS-X).

• Ви можете оглянути глибше за допомогою таких інструментів, як statабо statfsв каталозі. Однак для нормальних людей це трохи низький рівень, і досить часто такі інструменти добре приховані від звичайних користувачів.

• У каталогах можуть бути файли із забавними іменами. Як файл, який безпосередньою мірою стирає термінальний висновок, тому схоже, його там немає. Спробуйте щось на кшталт ls -al | lessабо використовуйте щось на зразок MidnightCommander mc.

Є багато інших можливих можливостей, включаючи помилок, хаксорів, прибульців або, можливо, більш екзотичні речі, такі як феї. Але зазвичай не розумно починати шукати там, натомість спершу спробуйте знайти помилку біля вас, тому що "помилково humanum est".

Це також може бути випадок, який я щойно вирішив, коли зламане символьне посилання було на стороні сервера і не було видно клієнту через CIFS. Симпосилання заповнювала не порожній каталог, але клієнт не зміг побачити або статтувати символьне посилання для очищення каталогу перед від’єднанням каталогу. Оскільки він був невидимим, він створив цей парадокс, коли з боку клієнта він був порожній, але "не порожній" при виклику rm . Якщо у вас є доступ SSH до сервера, спробуйте скористатися оболонкою на цьому кінці і побачити, чи справді каталог порожній чи, можливо, порушено символьні посилання. Я зміг це зробити на Drobo5N, і це врятувало мою недопалку.

Спробуйте відкрити цей каталог у Windows, можливо, у Mac OS щось не відображається. У мене виникли подібні проблеми після декількох операцій з копіюванням між Mac та Win PC: каталог був порожнім навіть у терміналі, але в Windows я знайшов прихований файл Windows, тому я успішно видалив каталог звідти.

У терміналі:

1. enter sudo su (Командний рядок повинен переключитися на щось на зразок sh-3.2#.)
2. перейдіть до батьківської папки тієї, яку потрібно видалити
3. увійти rm -rf TheDirectoryYouWantToDelete

Я зіткнувся з цією проблемою під час спроби видалити папку, яку використовував додаток. Коли я закрив додаток, він дозволив мені видалити папку, не викидаючи цю помилку, тому спробуйте вийти з програм, які можуть нею користуватися.