Próbowałem usunąć katalog przy użyciu „rm -rf” i pojawia się komunikat „Katalog nie jest pusty”:
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
Jeśli spróbuję tego samego za pomocą Findera (przeciągając folder do Kosza), otrzymam wiadomość
Operacji nie można ukończyć, ponieważ element „empty_directory” jest w użyciu.
Próbowałem robić to xattr -d com.apple.quarantine
wyłącznie z przesądów, ale nie przyniosło to pożytku.
Prawdopodobnie ważnym kontekstem jest to, że katalog ten początkowo znajdował się w katalogu, który powinien zostać usunięty przez polecenie „make clean” wydane przed zablokowaniem przez mnie terminala, po czym nieco ponad połowa innych programów, które miałem działający również zablokowany, w tym Skype, a ostatecznie sam system operacyjny. Skończyło się na tym, że musiałem ponownie uruchomić komputer, naciskając i przytrzymując klawisz zasilania.
Edytuj, aby dodać: Kolejną ważną informacją, którą odrzuciłem, było to, że działo się to w zaszyfrowanym folderze à la encfs
. Byłem w stanie wyśledzić odpowiedni folder w zaszyfrowanej stronie rzeczy i usunąć go tam. Nadal nie wiem, dlaczego nie mogłem tego zrobić z odszyfrowanej strony rzeczy, jak zwykle. Na razie pozostawię tę odpowiedź bez odpowiedzi, na wypadek, gdyby ktoś miał na to dobrą odpowiedź.
źródło
rmdir
- ale często jest to przyczyną, dla której nie można odmontować woluminu).Odpowiedzi:
Uruchom ponownie komputer i uruchom
rmdir(1)
ponownie.Jeśli to nie zadziała, spróbuj:
Jeśli nadal nie działa, zakładając, że OS X został
lsof(8)
wstępnie zainstalowany, wpisz:To powinno powiedzieć, czy jakieś programy w tym katalogu są używane przez jakiekolwiek programy. Myślę, że system plików HFS + nie pozwala na usuwanie używanych plików. W każdym razie
killall(1)
wszelkie pliki wykonywalne, które mogą korzystać z tego katalogu lub ukrytych plików w nim zawartych. Prawdopodobnie Finder używa ukrytego pliku wempty_directory
katalogu do przechowywania ustawień widoku folderów. Mam nadzieję że to pomoże.PS: Aby dowiedzieć się, czy
lsof(8)
jest zainstalowany, wprowadź:Jeśli dane wyjściowe wyglądają tak,
lsof(8)
oznacza to, że są zainstalowane w systemie.Sprawdź, czy w tym katalogu nie ma ukrytych i zaszyfrowanych plików lub plików kluczy szyfrowania. Mogą to być sprawcy.
źródło
Naprawienie dysku za pomocą Narzędzia dyskowego naprawiło ten problem.
źródło
Jeśli tak się stanie i na pewno chcesz usunąć wszystko, spróbuj użyć
sudo rm -rf directory/
źródło
Natrafiłem na dokładnie ten błąd podczas próby usunięcia katalogu (rm -r nazwa_katalogu). Wypróbowałem już wszystkie sugestie, które tu przeczytałem, zanim zacząłem szukać tego wątku. Nie wiem, czy mogły być jakieś dodatkowe punkty przypadkowo pozostawione bez odpowiedzi w stosunku do pierwotnego pytania, ale w moim przypadku źródłem problemu, a rozwiązaniem było:
dany katalog znajdował się na dysku podłączonym do sieci
każda
ls
próba z Findera lub wiersza poleceń nie wykazała nic oprócz.
i..
Zalogowałem się do sieciowego serwera dyskowego za pomocą
ssh
polecenia ils -al
tam sprawdziłem . Wynik pokazał, oprócz.
a..
, kilka.__filename
przedmiotów z rozszerzonym informacje bezpieczeństwa (tj+
załączonym do trybu).Wierzę, że to, czy są podobne do plików, które po raz pierwszy zaobserwowane Mac OSX tworząc lat temu podczas korzystania z
cp -R
,tar
lubcpio
do archiwizacji lub przenieść grupy plików. W tym czasie wydedukowałem, że były one używane do prawidłowego zresetowania niektórych właściwości pliku po przeniesieniu - może uid / gid, mode, acls, mtime / utime / ctime itp .; Nie jestem do końca pewien - właściwości, które wcześniej nie były poprawnie resetowane przez te polecenia (pamiętam, że OSX zawierałmvmac
icpmac
polecenia, aby obejść ten problem, zanim te.__filename
typy plików zaczęły pojawiać się przy użyciu zwykłych formcp
,tar
itp.).Nigdy nie napotkałem problemów z usunięciem tych plików, gdy zostały zapisane na dysku wewnętrznym, USB lub Firewire; po raz pierwszy znalazłem je na dysku sieciowym; całkowicie niewykrywalny po stronie klienta montowania, ale normalny pod każdym względem, gdy patrzy się na niego po stronie serwera.
rm -rf dirname
z loginu na sieciowym serwerze dyskowym prawidłowo usunął katalog wraz z jego zawartością.Jest jeszcze jedna odpowiedź na pytanie, ile jest warta; inne potencjalne rozwiązanie tego problemu, jeśli powinno pojawić się dla każdego w połączeniu z dyskiem sieciowym.
źródło
Wypróbowałem wszystkie odpowiedzi tutaj bez rezultatów. Byłem jednak w stanie przenieść katalog na bok za pomocą polecenia mv , co pozwoliło mi kontynuować.
źródło
Jedyne rozwiązanie, które działało dla mnie, to /unix/234876/unable-to-delete-a-file-whokolwiek-i-do :
Inne opcje, które wypróbowałem to:
lsof +D bad_file
nie pokazał wyników.rm -rf
.źródło
rm -rf
nielsof +D
pokazuje. Co dziwne, udało mi się przenieść katalogi obrażające do/tmp
, choć nie zostały usunięte po ponownym uruchomieniu. Ten sam problem pozostaje, ale przynajmniej jest trochę na uboczu.Z korzyścią dla czytelników:
Uważaj
rm -rf
w takim przypadku! Może stwarzać problemy gdzie indziej, na wypadek, gdyby był to udział sieciowy! Zostałeś ostrzeżony!W prawie wszystkich przypadkach, jeśli
directory
wydaje się być pusty, użyjrmdir directory
lub możesudo rmdir directory
. Nie używajrm
(lubdel
w systemie Windows). Jeśli to nie zadziała, musisz dowiedzieć się, co blokuje to żądanie, napraw je, a następnie ponów próbęrmdir
.Jest bardzo prawdopodobne, że dany katalog był po prostu punktem montowania (z pliku enfs) lub znajdował się w punkcie montowania, który stał się tylko do odczytu lub utknął w jakimś niewłaściwym stanie (co uniemożliwiło usunięcie katalogu). Jeśli wymusisz teraz usunięcie katalogu, mogą się zdarzyć bardzo złe rzeczy.
W dobrym przypadku katalog był naprawdę pusty, więc usunięcie go (zniszczenie mounta itp.) Nie spowodowało dalszych szkód. W złym przypadku nie był pusty, po prostu wyglądał, co oznacza, że zniszczyłeś coś, czego być może nie chciałeś zabić. Wszystko zależy od typu montażu, używanych sterowników itp. Pp.
Jeśli rzeczy są wdrażane dość dobrze, zwykle nic złego nie powinno się wydarzyć. Jednak nie jest to normalny przypadek. Sprawy są już w dziwnym stanie, co oznacza: Coś jest nie tak, więc lepiej nie próbuj ich mieszać! Jeśli coś pęknie, każde niewłaściwe dotknięcie może go złamać.
Na przykład, jeśli osiągniesz warunek wyścigu w udziale sieciowym, być może
rm -rf
usuniesz dane, które zostały skopiowane do udziału przez kogoś innego.Jednak
rmdir
gwarantuje, że nigdy nie zaszkodzi, oprócz usunięcia naprawdę pustych katalogów. Jest to nawet prawdą w przypadku NFS, ponieważ NFS gwarantuje tylko naprawdę atomowe zachowanie namkdir
irmdir
, ale nigdzie indziej.FYI:
Możesz wykryć punkt montowania za pomocą narzędzia
mountpoint directory
. Alternatywnie zajrzyj do wyjściamount
i spróbuj tam znaleźć swoje wierzchowce. Ale uwaga, przynajmniej pod Linuksem może to kłamać. Korzystanie zmountpoint
narzędzia jest bardziej niezawodne, ale mniej wygodne.W takim przypadku znalazłeś punkt montowania, możesz odmontować go, a następnie usunąć katalog, jest to następująca sekwencja:
umount directory rmdir directory
W razie potrzeby użyj
sudo
jak zwykle.Uwagi:
Udziały sieciowe mogą odmawiać
rmdir
(i cokolwiek innego) z powodu praw dostępu.Wadliwe systemy plików mogą odmówić
rmdir
, w zależności od strategii niepowodzenia. Być może w takim przypadku zobaczysz rozsądną wiadomość, a może nie.Pod Linuksem (i prawdopodobnie dowolnym współczesnym systemem operacyjnym) możesz również ograniczyć dostęp przy użyciu różnych środków (np. Montowanie czegoś tylko do odczytu, możliwości jak w SeLinux itp.). Oznacza to, że nie widzisz, że jest to punkt montowania i nie widzisz nic złego, ale po prostu nie działa. W takim przypadku musisz poszukać innego powodu, który może być bardzo głęboko ukryty w systemie operacyjnym. To zależy od narzędzia, jeśli zobaczysz jakiś rozsądny komunikat o błędzie. Być może zajrzyj także do syslog / kernel-log jak
dmesg
w Linuksie (przepraszam, nie znam odpowiednika OS-X).Pamiętaj, że obowiązkowe blokowanie plików może być również źródłem. Chociaż jest to normalne w systemie Windows, zwykle nie jest to normalny przypadek Uniksa i nigdy nie słyszałem tego w przypadku katalogów. Obowiązkowe blokady plików są objęte POSIX, ale są opcjonalne.
Dość często w takich przypadkach dany katalog znajduje się w innym systemie plików niż myślałeś. Możesz dowiedzieć się, które z poleceniem
df directory
(myślę, że to samo w OS-X).Możesz głębiej sprawdzić za pomocą narzędzi takich jak
stat
lubstatfs
w katalogu. Są to jednak nieco niski poziom dla normalnych ludzi i dość często takie narzędzia są dobrze ukryte przed normalnymi użytkownikami.Katalogi mogą mieć pliki o śmiesznych nazwach. Jak plik, który natychmiast kasuje wyjście terminala, więc wygląda na to, że go nie ma. Spróbuj czegoś takiego
ls -al | less
lub użyj czegoś takiego jak MidnightCommandermc
.Istnieje mnóstwo innych możliwości, w tym robaków, haxorów, kosmitów, a może bardziej egzotycznych rzeczy, takich jak wróżki. Ale zwykle nie jest mądre, aby zacząć tam szukać, zamiast tego najpierw spróbuj znaleźć błąd po swojej stronie, ponieważ „errare humanum est”.
źródło
Może to być również przypadek, który właśnie rozwiązałem, w którym zepsute dowiązanie symboliczne było po stronie serwera i nie było widoczne dla klienta przez CIFS. Dowiązanie symboliczne wypełniło niepusty katalog, ale klient nie był w stanie zobaczyć ani wygenerować dowiązania symbolicznego w celu wyczyszczenia katalogu przed odłączeniem katalogu. Ponieważ był niewidoczny, stworzył ten paradoks, w którym ze strony klienta był pusty, ale „nie pusty” na wyzwanie przez rm . Jeśli masz dostęp SSH do serwera, wypróbuj powłokę na tym końcu i sprawdź, czy katalog jest naprawdę pusty lub czy może mieć zepsute dowiązania symboliczne. Byłem w stanie to zrobić na Drobo5N i to uratowało mi tyłek.
źródło
Spróbuj otworzyć ten katalog z Windows, może być coś nie pokazanego w Mac OS. Miałem podobny problem po kilku operacjach kopiowania między komputerem Mac a Win PC: katalog był pusty nawet w terminalu, ale w systemie Windows znalazłem ukryty plik systemu Windows, więc udało mi się go usunąć.
źródło
W terminalu:
sudo su
(wiersz polecenia powinien zmienić się na coś takiegosh-3.2#
.)rm -rf TheDirectoryYouWantToDelete
źródło
Napotkałem ten problem podczas próby usunięcia folderu używanego przez aplikację. Po zamknięciu aplikacji mogę usunąć folder bez zgłaszania tego błędu, więc spróbuj zamknąć aplikacje, które mogą go używać.
źródło