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

Изменить, чтобы добавить: Другая важная информация, которую я остановил, заключалась в том, что это происходило в зашифрованной папке а-ля 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). Я уже перепробовал все предложения, которые я прочитал здесь, прежде чем искать и найти эту тему. Я не знаю, были ли какие-либо дополнительные моменты, непреднамеренно оставленные неустановленными из исходного вопроса, но в моем случае корень проблемы, и решение было:

• рассматриваемый каталог находился на сетевом диске

• любая 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-whwhat-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) или находился в точке монтирования, которая стала доступна только для чтения или застряла в каком-то неправильном состоянии (что препятствовало удалению каталога). Если вы сейчас принудительно удалите каталог, могут произойти очень плохие вещи.

В хорошем случае каталог действительно был пустым, поэтому удаление его (уничтожение монтирования и т. Д.) Больше не повредило. В плохом случае это было не пусто, просто казалось, что означает, что вы уничтожили что-то, что, возможно, не хотели убивать. Все зависит от типа монтирования, используемых драйверов и т. П.

Если все реализовано достаточно хорошо, обычно ничего плохого не должно произойти. Однако это не нормальный случай. Все уже в странном состоянии, что означает: что-то не так, так что лучше не пытайтесь смешивать это еще дальше! Если что-то сломано, любое неправильное прикосновение может сломать это.

Например, если вы столкнулись с состоянием гонки на общем сетевом ресурсе, может случиться так, что вы 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.

Есть множество других возможностей, включая жуков, хакшоров, инопланетян или, возможно, более экзотические вещи, такие как феи. Но обычно не стоит начинать искать там, вместо этого сначала попытайтесь найти ошибку на вашей стороне, потому что «errare humanum est».

Это также может быть случай, который я только что решил, когда сломанная символическая ссылка была на стороне сервера и не была видна клиенту через CIFS. Символьная ссылка заполнила непустой каталог, но клиент не смог увидеть или оценить символическую ссылку с целью очистки каталога перед удалением связи с каталогом. Поскольку он был невидимым, он создал этот парадокс, когда со стороны клиента он был пустым, но «не пустым» при вызове rm . Если у вас есть SSH-доступ к серверу, попробуйте на этом конце оболочку и посмотрите, действительно ли каталог пуст или имеет битые символические ссылки. Я смог сделать это на Drobo5N, и это спасло мою задницу.

Попробуйте открыть этот каталог из Windows, может быть, что-то не отображается в Mac OS. У меня была похожая проблема после ряда операций копирования между Mac и Win PC: каталог был пустым даже в терминале, но в Windows я обнаружил скрытый файл Windows, поэтому успешно удалил каталог оттуда.

В терминале:

1. введите sudo su (приглашение командной строки должно переключиться на что-то вродеsh-3.2# .)
2. перейдите в родительскую папку того, который вы хотите удалить
3. войти rm -rf TheDirectoryYouWantToDelete

Я столкнулся с этой проблемой при попытке удалить папку, которая использовалась приложением. Когда я закрыл приложение, оно позволило мне удалить папку, не выдавая эту ошибку, поэтому попытайтесь закрыть приложения, которые могут ее использовать.