Dlaczego istnieją twarde linki?

Wiem, jakie są twarde linki, ale dlaczego miałbym ich używać? Jaka jest użyteczność twardego łącza?

Główną zaletą linków twardych jest to, że w porównaniu do linków miękkich nie ma ograniczenia rozmiaru ani prędkości. Miękkie linki to dodatkowa warstwa pośrednicząca nad normalnym dostępem do plików; jądro musi wyłuskać link podczas otwierania pliku, a to zajmuje trochę czasu. Łącze zajmuje również niewielką ilość miejsca na dysku, aby pomieścić tekst łącza. Kary te nie istnieją w przypadku twardych dowiązań, ponieważ są wbudowane w samą strukturę systemu plików.

Najlepszym sposobem, aby to zobaczyć, jest:

$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../

-iOpcja lssprawia, że daje numer i-węzła pliku. W systemie, w którym przygotowałem powyższy przykład, znalazłem się w katalogu z i-węzłem o numerze 1069765, ale konkretna wartość nie ma znaczenia. To tylko unikalna wartość identyfikująca konkretny plik / katalog.

Mówi to, że kiedy wchodzimy do podkatalogu i patrzymy na inny wpis o nazwie systemu plików .., ma on ten sam numer i-węzła, jaki wcześniej. Nie dzieje się tak, ponieważ powłoka interpretuje ..dla ciebie, tak jak dzieje się to w MS-DOS i Windows. W systemach plików Unix ..jest to prawdziwy wpis do katalogu; jest to twardy link prowadzący do poprzedniego katalogu.

Twarde linki to ścięgna, które łączą ze sobą katalogi systemu plików. Dawno, dawno temu Unix nie miał twardych linków. Zostały dodane, aby zmienić oryginalny płaski system plików Unixa w hierarchiczny system plików.

(Aby uzyskać więcej informacji na ten temat, zobacz Dlaczego „/” ma wpis „..”? )

Jest również dość powszechne w systemach Unix dla kilku różnych poleceń, które mają być implementowane przez ten sam plik wykonywalny. Wydaje się, że już tak nie jest w Linuksie, ale w systemach, z których korzystałem w przeszłości cp, mvi rmwszystkie były tak samo wykonywalne. Ma to sens, jeśli się nad tym zastanowić: kiedy przenosisz plik między woluminami, jest to faktycznie kopia, po której następuje usunięcie, więc mvjuż musiałem zaimplementować funkcje pozostałych dwóch poleceń. Plik wykonywalny może dowiedzieć się, którą operację wykonać, ponieważ otrzymuje nazwę, przez którą został wywołany.

Innym przykładem, powszechnym we wbudowanych systemach Linux, jest BusyBox , pojedynczy plik wykonywalny, który implementuje dziesiątki poleceń.

Powinienem zaznaczyć, że w większości systemów plików użytkownicy nie mogą tworzyć twardych linków do katalogów. .I ..wpisy są automatycznie zarządzane przez kod systemu plików, który jest zazwyczaj częścią jądra. Ograniczenie istnieje, ponieważ możliwe jest spowodowanie poważnych problemów z systemem plików, jeśli nie będziesz ostrożny ze sposobem tworzenia i używania twardych linków do katalogu. Jest to jeden z wielu powodów, dla których istnieją miękkie linki; nie niosą tego samego ryzyka.

Jednym z niezwykle przydatnych zastosowań twardych dowiązań jest tworzenie przyrostowych kopii zapasowych w połączeniu z rsync. Oszczędza dużo miejsca i sprawia, że ​​procedura przywracania jest naprawdę łatwa. Używam tego podejścia do tworzenia kopii zapasowych na moich serwerach.

Poświęć trochę czasu na przeczytanie tego wyjaśnienia .

Jeśli po przeczytaniu tej strony wikipedii masz pytanie „dlaczego miałbym ich kiedykolwiek używać”, to nie rozumiesz, jakie są twarde linki.

Ogniwo jest pozycja katalogu, który wskazuje na bloków na dysku. Innymi słowy, każdy plik w systemie ma co najmniej jeden link. W rmprzypadku pliku rzeczywiste wywołanie systemowe to unlink(). Usuwa pozycję katalogu. Bloki na dysku nie uległy zmianie, ale łącze zniknęło, dlatego plik zniknął z listy katalogów.

Osobiście nie możesz nigdy używać twardych linków, ale są one w całym systemie. Na przykład:

$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzip2

Widać, że bunzip2, bzcati bzipwszyscy korzystają z tego samego iwęzeł. Zasadniczo jest to jeden plik z trzema nazwami. Państwo mogłoby mieć trzy kopie pliku, ale dlaczego? Zużyłoby tylko niepotrzebnie miejsce na dysku.

Istnieje dowolna liczba zastosowań. Używam ich do tworzenia blokad opartych na plikach. Wywołanie systemowe link (2) ma charakter atomowy, w przeciwieństwie do większości innych wywołań systemowych.

Innym zastosowaniem jest rsnapshot, w którym kopie zapasowe są tworzone z czasem za pomocą twardych łączy w celu zmniejszenia ilości miejsca na dysku. Jeśli plik się nie zmienił, plik jest na stałe połączony ze starszymi instancjami pliku, a zmienione pliki są kopiowane od nowa.

Używam ich również do wymiany plików konfiguracyjnych na serwerach: rm file.cfg && ln ~/tmp/file.cfg file.cfgwtedy pliki ~ / tmp / * można bezpiecznie usunąć.

Aby dodać do kilku dobrych dyskusji już obecnych ...

• Sposób, w jaki dostęp do zasobów programów jest implementowany w systemie Unix (tzn. „Wszystko jest plikiem” ), oznacza, że ​​infrastruktura do obsługi wielu odwołań do pliku jest wymagana, aby system operacyjny w ogóle działał, więc nie ma tutaj dodatkowych kosztów.
• Sposób, w jaki katalogi zostały zaimplementowane w oryginalnych systemach plików uniksowych (tj. Lista (inode, name)par o stałym formacie oznacza, że ​​w systemie plików nie ma żadnych dodatkowych kosztów związanych z posiadaniem dowiązań twardych (o ile zapobiegamy cyklom poprzez niedozwolenie dowiązań twardych do katalogów (innych niż .i ..(czy to zaczyna czuć się jak seplenienie wobec kogokolwiek innego?)))

więc otrzymujemy je za darmo.

Prawdopodobnie powinienem opisać scenariusz pułapek twardych linków. Twardy link będzie tym samym plikiem o innej nazwie i / lub innej lokalizacji, o ile istnieje oryginalny linkowany plik . Nie jest nawet poprawne uznanie pliku za „oryginalny”: oba są wpisami do katalogu same w sobie, a oba (lub więcej) są równorzędne. W przypadku plików długowiecznych może to być błogosławieństwo, ale jeśli jedna z pary zostanie usunięta, a następnie utworzona, nawet z tą samą nazwą i zawartością, pliki zostaną rozdzielone.

Załóżmy, że utworzyłeś /foo/myfilelink dowiązujący do /repo/myfile. Oba są wskaźnikami do tych samych danych pliku; zmień jeden, drugi zmień. Załóżmy jednak, że tak się /repodzieje, że zawiera repozytorium Git. Jeśli zaznaczysz gałąź, która myfilew niej nie zawiera , /repo/myfilezostanie usunięta. W tym momencie /foo/myfilestaje się prostą kopią /repo/myfile, jakby to było w momencie, gdy druga para została odłączona. Łatwo nawet nie zauważyć, gdy przerzucasz się między gałęziami, które zapisują zmiany w repertuarze, ale kiedy kasujesz oryginalną gałąź, nowy plik/repo/myfilejest tworzony przez Git. Gdybyś nie zwrócił na to uwagi, zastanawiałbyś się, dlaczego te dwa pliki mają teraz różną zawartość, chociaż łatwo jest się zorientować, ponieważ twarde powiązanie między plikami nie ma pojęcia o ich nazwach. Natomiast miękki link przetrwałby w tym cyklu usuwania i tworzenia.

Z drugiej strony oprogramowanie, które korzysta z twardych linków, jest tego w pełni świadome, a Git jest tego doskonałym przykładem. Git klonuje repozytorium w tym samym systemie plików prawie za darmo, ponieważ domyślnie używa twardych łączy zamiast kopiować pliki. Dla Git twardy link jest doskonałym przykładem użycia, ponieważ jego pliki obiektów i pakietów nigdy się nie zmieniają, więc jeden klon repozytorium nigdy nie zmieni drugiego (Git nie wie, że można modyfikować pliki modyfikowalne na stałe), a dowolny z klonów może być usunięte bez żadnych środków ostrożności: nie ma potrzeby śledzenia, który z nich jest „oryginalny” i faktycznie zawiera pliki: każdy z twardych linków jest równym partnerem i „zawiera” pełny plik. Miękkie linki po prostu by tu nie działały.

Kolejną zaletą twardego linku jest to, że dowolne łącze można przenieść bez przerywania dostępu do zawartości pliku. Przy miękkich linkach przeniesienie oryginalnego pliku powoduje, że wszystkie miękkie linki do niego zwisają.

Najważniejsze jest to, że w wielu przypadkach użycia każdy typ linku działa równie dobrze, ale w jednym lub drugim typie jest korzystny. Wydajność, o której wspomniano w wielu odpowiedziach tutaj, jest prawdopodobnie bardzo mało istotna w przypadku nowoczesnych maszyn i systemów plików, chyba że oczyszczasz system plików na układzie FLASH słabego wbudowanego kontrolera. Te różnice funkcjonalne są ważniejsze, a zwykle dyktować ograniczenia techniczne i ostateczny wybór:

• Twarde łącze „źródło” można bezpiecznie przenosić, podczas gdy miękkie łącze się zepsuje.
• Dowiązanie twarde jest nierozróżnialne od pliku, z którego zostało połączone, a plik jest aktywny tak długo, jak długo istnieje jeden z twardych łączy; miękkie łącze jest asymetryczne.
• Twardy link wyłamuje się z połączonej grupy, jeśli zostanie usunięty i utworzony ponownie, ale miękki link nie traci swojego celu.
• Miękki link może przenikać przez systemy plików, a twardy link nie.
• Miękki link może wskazywać na katalog, twardy link zwykle nie może (i praktycznie zawsze nie powinien).

Poza tym muszę wskazać, że wywołanie biblioteki usuwające plik jest wywoływane unlink()z jakiegoś powodu! Każda pozycja katalogu jest początkowo pojedynczym twardym łączem do jej i-węzła.