Dlaczego twarde linki wydają się zajmować tyle samo miejsca co oryginały?


14

Dzięki dobrym pytaniom i odpowiedziom na tej stronie i na tej stronie rozumiem teraz linki. Widzę, że twarde łącza odnoszą się do tego samego i-węzła inną nazwą, a kopie są różnymi „węzłami” o różnych nazwach. Plus miękkie łącza mają oryginalną nazwę i ścieżkę pliku jako i-węzeł, więc jeśli plik zostanie przeniesiony, łącze się zepsuje.

Przetestowałem to, czego się nauczyłem z jakimś plikiem („saluton_mondo.cpp” poniżej), utworzyłem twardy i miękki link oraz kopię.

jmcf125@VMUbuntu:~$ ls -lh soft hard copy s*.cpp
-rw-rw-r-- 1 jmcf125 jmcf125 205 Aŭg 27 16:10 copy
-rw-rw-r-- 2 jmcf125 jmcf125 205 Aŭg 25 13:34 hard
-rw-rw-r-- 2 jmcf125 jmcf125 205 Aŭg 25 13:34 saluton_mondo.cpp
lrwxrwxrwx 1 jmcf125 jmcf125  17 Aŭg 27 16:09 soft -> saluton_mondo.cpp

Uznałem, że niezręczne jest to, że twardy link ma taki sam rozmiar jak oryginał i logicznie kopia. Jeśli twardy link i oryginalny mają ten sam i-węzeł, który ma dane i różnią się tylko nazwą pliku, czy twardy link nie powinien zajmować tylko miejsca jego nazwy, zamiast 205 bajtów? Czy jest to rozmiar oryginalnego pliku, który ls -lhzwraca? Ale skąd mam wiedzieć, ile miejsca zajmuje nazwa pliku? Tutaj mówi się, że twarde linki nie mają rozmiaru. Czy ich nazwa pliku jest przechowywana obok oryginalnej nazwy pliku? Gdzie jest przechowywana nazwa pliku twardych linków?

Odpowiedzi:


17

Plik to i-węzeł z meta danymi, wśród których znajduje się lista wskaźników wskazujących, gdzie znaleźć dane.

Aby uzyskać dostęp do pliku, musisz połączyć go z katalogiem (traktuj katalogi jak katalogi telefonu, a nie foldery), czyli dodaj jeden lub więcej wpisów do jednego lub więcej katalogów, aby powiązać nazwę z tym plikiem.

Wszystkie te linki, nazwy plików wskazują na ten sam plik. Nie ma jednego, który jest oryginalny, a innych, które są linkami. Wszystkie są punktami dostępu do tego samego pliku (tego samego i-węzła) w drzewie katalogów. Gdy uzyskasz rozmiar pliku ( lstatwywołanie systemowe), pobierasz informacje (o których mowa powyżej) przechowywane w i-węzle, nie ma znaczenia, której nazwy pliku i linku używasz w celu odniesienia do tego pliku .

Natomiast dowiązania symboliczne to inny plik (inny i-węzeł), którego treść jest ścieżką do pliku docelowego. Jak każdy inny plik, te dowiązania symboliczne muszą być połączone z katalogiem (muszą mieć nazwę), abyś mógł uzyskać do nich dostęp. Możesz także mieć kilka linków do dowiązań symbolicznych, innymi słowy, dowiązaniom symbolicznym można nadać kilka nazw (w jednym lub kilku katalogach).

$ touch a
$ ln a b
$ ln -s a c
$ ln c d
$ ls -li [a-d]
10486707 -rw-r--r-- 2 stephane stephane 0 Aug 27 17:05 a
10486707 -rw-r--r-- 2 stephane stephane 0 Aug 27 17:05 b
10502404 lrwxrwxrwx 2 stephane stephane 1 Aug 27 17:05 c -> a
10502404 lrwxrwxrwx 2 stephane stephane 1 Aug 27 17:05 d -> a

Nad numerem pliku 10486707 znajduje się zwykły plik. Dwa wpisy w bieżącym katalogu (jeden z imieniem a, drugi z imieniem b) prowadzą do niego. Ponieważ liczba linków wynosi 2, wiemy, że nie ma innej nazwy tego pliku w bieżącym katalogu ani w żadnym innym katalogu. Plik o numerze 10502404 to kolejny plik, tym razem typu dowiązanie symboliczne dwukrotnie połączone z bieżącym katalogiem. Jego zawartość (cel) jest ścieżką względną „a”.

Zauważ, że jeśli 10502404 był połączony z innym katalogiem niż bieżący, zwykle wskazywałby na inny plik w zależności od sposobu dostępu.

$ mkdir 1 2
$ echo foo > 1/a
$ echo bar > 2/a
$ ln -s a 1/b
$ ln 1/b 2/b
$ ls -lia 1 2
1:
total 92
10608644 drwxr-xr-x   2 stephane stephane  4096 Aug 27 17:26 ./
10485761 drwxrwxr-x 443 stephane stephane 81920 Aug 27 17:26 ../
10504186 -rw-r--r--   1 stephane stephane     4 Aug 27 17:24 a
10539259 lrwxrwxrwx   2 stephane stephane     1 Aug 27 17:26 b -> a

2:
total 92
10608674 drwxr-xr-x   2 stephane stephane  4096 Aug 27 17:26 ./
10485761 drwxrwxr-x 443 stephane stephane 81920 Aug 27 17:26 ../
10539044 -rw-r--r--   1 stephane stephane     4 Aug 27 17:24 a
10539259 lrwxrwxrwx   2 stephane stephane     1 Aug 27 17:26 b -> a
$ cat 1/b
foo
$ cat 2/b
bar

Pliki nie mają powiązanych z nimi nazw innych niż w katalogach, które je łączą. Miejsce zajmowane przez ich nazwy to wpisy w tych katalogach, jest to uwzględnione w wielkości pliku / wykorzystaniu dysku przez katalogi.

Zauważysz, że wywołanie systemowe w celu usunięcia pliku to unlink. Oznacza to, że nie usuwasz plików, odłączasz je od katalogów, do których się odnoszą. Po odłączeniu od ostatniego katalogu, w którym znajdował się wpis do danego pliku, plik ten jest następnie niszczony (dopóki nie ma go żaden proces otwierany).


Ahh ... Teraz rozumiem. Plik o nazwie „cześć” i jego dokładna kopia o nazwie „ajhĝjdmjefsjmksgskgjkmŝŭna” zajmują dokładnie tyle samo miejsca; ponieważ ich nazwy nie liczą się dla tego lstatwywołania systemowego, które dostaje ich rozmiar.
JMCF125,

@ JMCF125, tak rozmiar podany przez ich nazwy jest wpisem w odpowiednich katalogach, jest uwzględniony w wielkości pliku katalogów.
Stéphane Chazelas

Dzięki. Czy możesz to uwzględnić w swojej odpowiedzi? Zaczekaj, najpierw wyjaśnię moje pytanie.
JMCF125,

5

Twardy link to zasadniczo oryginalny plik. Tak więc rozmiar, który widzisz, jest wielkością pliku, do którego prowadzi łącze. To miękkie linki, które zajmują tylko przestrzeń ich nazw (trochę).

Jeśli chodzi o system plików, twardy link i oryginał są tym samym, wskazują na ten sam i-węzeł, więc zgłaszany jest ten sam rozmiar.


Ale nazwa twardego łącza musi zająć miejsce, prawda?
JMCF125,

Zobacz odpowiedź @ Stephan poniżej, on wyjaśnia to lepiej.
terdon

2
@ JMCF125 Tak, ale to miejsce znajduje się w katalogu. Jeśli utworzysz wystarczającą liczbę plików, zauważysz, że rozmiar katalogu wzrasta. Rozmiar pliku nie obejmuje jego metadanych, takich jak nazwa.
Gilles „SO- przestań być zły”

@Gilles, dzięki, ale @Stephane już zaktualizował swoją odpowiedź o te informacje. Ponadto, teraz myślę o tym lepiej, nazwa /musi być przechowywana sama w sobie, tak jakbyś cd ..w niej /pozostał /.
JMCF125,
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.