Попытка удалить каталог с помощью "rm -rf", но получить сообщение, что оно не пустое

Перезагрузите компьютер и запустите 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 не показал выходной.
• sudo rm -rf
• Загрузка в однопользовательский терминал и rm -rf,

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

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

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

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

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

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

берегись rm -rf в таком случае! Это может создать проблемы где-то еще в случае, если это будет сетевой ресурс! Вы были предупреждены!

Почти во всех случаях, если directory кажется пустым, используйте rmdir directory или возможно sudo rmdir directory , Не использовать rm (или же del под виндой). Если это не работает, вам нужно выяснить, что блокирует этот запрос, исправить это, а затем повторить попытку. 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".

Если файл/папка находятся в смонтированном томе на Mac. Размонтирование и монтирование тома может решить проблему.

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

В терминале:

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

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

У меня такая же проблема.
Решил это загрузкой на другом томе MacOS или диске. Потом:

sudo rm -rf /Volume/volumewithproblem/directorywithproblem

Откройте терминал и введите:

1. Эта команда

   defaults write com.apple.finder AppleShowAllFiles YES
   

2. Нажмите кнопку option, щелкните правой кнопкой мыши Finder и выберите перезапуск.

3. Затем перейдите в Volume на рабочем столе, откройте .Trashes/Trashщелкните правой кнопкой мыши каталог и выберите пустую корзину
4. Готово

5. Затем в типе терминала:

   defaults write com.apple.finder AppleShowAllFiles No