Dlaczego nie mogę usunąć „.” informator?


40

Próbowałem usunąć „.” informator. Myślałem, że mogę po prostu usunąć mój katalog roboczy bez konieczności przechodzenia do katalogu nadrzędnego.

Celem mojego pytania jest poszukiwanie wglądu w działanie systemu Linux do usuwania plików.


1
Spróbuj
wykonać komendę

7
To pytanie nie powiela tego. To pytanie dotyczy tego, dlaczego łącze twarde istnieje raczej jako fizyczna istota niż synteza. To pytanie nie tylko pyta, dlaczego rm .i rmdir .nie działa, ale dlaczego określono je jako niedziałające, niezależne od fizycznego istnienia twardego łącza.
JdeBP,

9
Obraz wspiął się na drzewo, aby odciąć gałąź. Po której stronie cięcia siedzisz, kiedy zaczynasz piłować? (To jest system plików Linux w pigułce).
Michael

7
Wyobraź sobie, że robisz rm -rf .*to tylko nie tylko, .ale także .., a potem ../.., a potem…
gerrit,

Odpowiedzi:


89

Usunięcie bieżącego katalogu nie wpływa na integralność systemu plików ani jego logiczną organizację. Zapobieganie .usuwaniu odbywa się zgodnie ze standardem POSIX, który stwierdza na rmdir(2)stronie podręcznika:

Jeśli argument ścieżki odnosi się do ścieżki, której końcowym składnikiem jest kropka lub kropka-kropka, rmdir () zawiedzie.

Jedno uzasadnienie można znaleźć na rmstronie podręcznika:

Narzędzie rm nie może usuwać nazw kropka-kropka-kropka, aby uniknąć konsekwencji niezamierzonego zrobienia czegoś takiego:

rm -r. *

Z drugiej strony, jawne usunięcie bieżącego katalogu (tj. Poprzez podanie jego pełnej lub względnej ścieżki) jest dozwoloną operacją w systemie Unix, przynajmniej od SVR3, ponieważ było to zabronione w systemie Unix w wersji 7 do SVR2. Jest to bardzo podobne do tego, co dzieje się po usunięciu pliku, który jest aktywnie odczytywany lub zapisywany. Procesy uzyskujące dostęp do pliku usuwania kontynuują operacje odczytu i zapisu, tak jakby nic się nie wydarzyło. Po usunięciu bieżącego katalogu procesu ten katalog nie jest już dostępny, ale jego i-węzeł pozostaje w systemie plików, dopóki proces nie umrze lub nie zmieni własnego katalogu.

Zauważ, że proces nie będzie mógł użyć ścieżki względem bieżącego katalogu do zmiany cwd (np. cd ..), Ponieważ nie ma już ..wpisu w jego bieżącym katalogu.

Kiedy rodzaj ktoś rmdir ., oni prawdopodobnie oczekują, że aktualny wpis do katalogu zostać usunięty, ale kiedy katalog jest usuwana (przy użyciu jego ścieżki), trzy wpisy w katalogach są faktycznie usunięte, ., .., a katalog sam.

Usunięcie tylko .tego katalogu, a nie wpisu tego katalogu, spowodowałoby utworzenie katalogu niezgodnego, ale jak już wspomniano, jest to zabronione przez standard.

Jak słusznie zauważył @Emmanuel, istnieje drugi powód, dla którego usunięcie .jest niedozwolone. Istnieje co najmniej jeden system operacyjny zgodny z POSIX (Mac OS X z HFS +), który z silnymi ograniczeniami obsługuje tworzenie twardych dowiązań do istniejących katalogów. W takim przypadku z katalogu nie ma jasnego sposobu, aby dowiedzieć się, który hardlink ma zostać usunięty.


9
pubs.opengroup.org/onlinepubs/9699919799/functions/rmdir.html "Znaczenie usuwania ścieżki / kropki jest niejasne, ponieważ nazwa pliku (katalogu) w katalogu nadrzędnym, który ma zostać usunięty, jest niejasna, szczególnie w obecności wielu linków do katalogu ”
Emmanuel,

@Emmanuel Usuwanie katalogu, który ma więcej niż dwa łącza (tzn. Nie jest puste), jest już zabronione z założenia (niepusty katalog). Standardowo katalog z linkiem jeden jest zabroniony (przynajmniej w systemach plików, w których liczba linków ma znaczenie).
jlliagre

3
@jlliagre: To nie jest kwestia katalogu zawierającego wiele linków, ale katalog z wieloma linkami. Niektóre systemy plików i / lub systemy operacyjne nie pozwalają na to, ale nie wszystkie.
Jörg W Mittag,

@ JörgWMittag Katalog zawierający wiele katalogów zawiera wiele łączy zgodnie z projektem, ponieważ wszystkie jego podkatalogi prowadzą ..do niego. Jest to wyjątkowy przypadek link count > 2przytłaczającej większości systemów operacyjnych i systemów plików, więc „niektóre systemy plików i / lub systemy operacyjne” to mało powiedziane. Jedynym nie znanym historycznie wyjątkiem jest Mac OS X z HFS +, który dodaje ograniczenia dotyczące tego, kto i co można zrobić. Przyznano, że komentarz POSIX jest skierowany do tej osobliwości. Zobacz unix.stackexchange.com/questions/22394/…
jlliagre,

Hej, zrobiłem już rm -r .*wcześniej i rekurencyjnie zniszczyło wszystko w katalogu nadrzędnym ... To było ponad dekadę lub dwie temu, ale miło jest wiedzieć, rmże już na to nie pozwala.
antak

9

Robi się to tak, aby zachować integralność, ponieważ obecnie znajdujesz się w tym katalogu, a .jest to tylko odnośnik.

Musisz albo przejść do jego obiektu nadrzędnego, albo wywołać rmdirjego ścieżkę, co można zrobić za pomocą:

rmdir `pwd`

Jeśli często tego potrzebujesz, możesz ustawić alias:

alias rmc='rmdir `pwd`'

.. które można nazwać rmcsamodzielnie, aby usunąć bieżący katalog.


13
Ale dlaczego / w jaki sposób hipotetyczne rmdir .polecenie narusza integralność systemu plików w sposób, rmdir $(pwd)czy rmdir "$PWD"nie?
G-Man mówi „Przywróć Monikę”

4
Nie chodzi o integralność FS, ale o logiczną organizację. Kiedy wybierasz swój bieżący katalog, mówisz powłoce, aby używała tego katalogu do nadchodzących operacji, ale nie możesz usunąć czegoś z siebie.
Julie Pelletier,

7
Obawiam się, że wygląda to hipotetycznie.
Emmanuel,

4
@FranklinPiat Nie uważam twojego komentarza za szczególnie przydatny: 1. Gdzie używał PO rm *i co rozumiesz przez historię powłok? 2. Odpowiedź dotyczyła części dlaczego , 3. Chcesz opracować?
JBentley,

4
@ G-Man, jeśli tak rmdir $(pwd), pwdna przykład wymyśla logiczną nazwę bieżącego katalogu, /foo/bar/baza następnie rmdir, widząc tę ​​ścieżkę, usuwa bazwpis z /foo/barkatalogu, pod warunkiem spełnienia warunków. To ma sens. Z rmdir .drugiej strony polecenie jest instrukcją usuwania .wpisu z bieżącego katalogu, co nie jest ani dozwolone (naruszałoby ograniczenie, że każdy katalog ma .wpis skierowany do siebie), ani użyteczne (nie usuwa łącza ty chciał usuwane).
hobbs
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.