27

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

8 ответов8

9

Перезагрузите компьютер и снова запустите 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

Проверьте наличие скрытых и зашифрованных файлов или файлов ключей шифрования в этом каталоге. Это может быть виновником.

3

Восстановление диска с помощью Дисковой утилиты устранило эту проблему для меня.

2

Если это произойдет, и вы уверены, что хотите удалить все, попробуйте использовать sudo rm -rf directory/

1

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

Итак, есть другой ответ, что это стоит; другое потенциальное решение этой проблемы, если оно появится у кого-либо вместе с сетевым диском.

1

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

1

В интересах читателей:

Остерегайтесь 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 и попробуйте найти там ваши mounts. Но будьте осторожны, по крайней мере, под 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".

1

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

0

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .