Próbuję usunąć katalog z „rm -rf”, ale dostaję wiadomość, że nie jest pusty

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.quarantinewyłą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ź.

Uruchom ponownie komputer i uruchom rmdir(1)ponownie.

$ rmdir -r empty_directory/

Jeśli to nie zadziała, spróbuj:

$ rm -rf empty_directory/

Jeśli nadal nie działa, zakładając, że OS X został lsof(8)wstępnie zainstalowany, wpisz:

$ lsof +D empty_directory/

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 w empty_directorykatalogu do przechowywania ustawień widoku folderów. Mam nadzieję że to pomoże.

PS: Aby dowiedzieć się, czy lsof(8)jest zainstalowany, wprowadź:

$ lsof

Jeśli dane wyjściowe wyglądają tak, lsof(8)oznacza to, że są zainstalowane w systemie.

lsof: /usr/bin/lsof /usr/bin/X11/lsof /usr/share/man/man8/lsof.8.gz

Sprawdź, czy w tym katalogu nie ma ukrytych i zaszyfrowanych plików lub plików kluczy szyfrowania. Mogą to być sprawcy.

Naprawienie dysku za pomocą Narzędzia dyskowego naprawiło ten problem.

Jeśli tak się stanie i na pewno chcesz usunąć wszystko, spróbuj użyć sudo rm -rf directory/

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 lspróba z Findera lub wiersza poleceń nie wykazała nic oprócz .i..

• Zalogowałem się do sieciowego serwera dyskowego za pomocą sshpolecenia i ls -altam sprawdziłem . Wynik pokazał, oprócz .a .., kilka .__filenameprzedmiotó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, tarlub cpiodo 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ł mvmaci cpmacpolecenia, aby obejść ten problem, zanim te .__filenametypy plików zaczęły pojawiać się przy użyciu zwykłych form cp, taritp.).

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.

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ć.

Jedyne rozwiązanie, które działało dla mnie, to /unix/234876/unable-to-delete-a-file-whokolwiek-i-do :

Przenieś je do / tmp i uruchom ponownie.

Inne opcje, które wypróbowałem to:

• Narzędzie dyskowe - pierwsza pomoc.
• lsof +D bad_file nie pokazał wyników.
• sudo rm -rf
• Ładowanie do terminala dla jednego użytkownika i rm -rf.

Z korzyścią dla czytelników:

Uważaj rm -rfw 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 directorywydaje się być pusty, użyj rmdir directorylub może sudo rmdir directory. Nie używaj rm(lub delw 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.

Proszę zauważyć, że nie znam OS-X, ale myślę, że rzeczy są bardzo podobne do zachowania Unix / BSD.

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 -rfusuniesz dane, które zostały skopiowane do udziału przez kogoś innego.

Jednak rmdirgwarantuje, ż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 na mkdiri rmdir, ale nigdzie indziej.

FYI:

Możesz wykryć punkt montowania za pomocą narzędzia mountpoint directory. Alternatywnie zajrzyj do wyjścia mounti spróbuj tam znaleźć swoje wierzchowce. Ale uwaga, przynajmniej pod Linuksem może to kłamać. Korzystanie z mountpointnarzę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 sudojak 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 dmesgw 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 statlub statfsw 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 | lesslub użyj czegoś takiego jak MidnightCommander mc.

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”.

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.

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ąć.

W terminalu:

1. enter sudo su (wiersz polecenia powinien zmienić się na coś takiego sh-3.2#.)
2. przejdź do folderu nadrzędnego folderu, który chcesz usunąć
3. wchodzić rm -rf TheDirectoryYouWantToDelete

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ć.