Twardy odnośnik to po prostu dodatkowa nazwa istniejącego pliku w Linuksie lub innych uniksopodobnych systemach operacyjnych.

Dla dowolnego pliku można utworzyć dowolną liczbę twardych odnośników, a tym samym dowolną liczbę nazw. Twarde dowiązania mogą być również tworzone do innych twardych dowiązań. Nie można ich jednak tworzyć dla katalogów i nie mogą one przekraczać granic systemów plików ani rozprzestrzeniać się między partycjami.

System operacyjny nie czyni rozróżnienia między nazwą, która została pierwotnie przypisana do pliku, gdy został on po raz pierwszy utworzony, a wszelkimi twardymi łączami, które są później tworzone do tego pliku, poza tym, że są one po prostu wieloma nazwami tego samego pliku. Dzieje się tak dlatego, że oryginalna nazwa i wszystkie twarde dowiązania wskazują na ten sam węzeł inode. Kod inode jest strukturą danych (tj. zoptymalizowanym sposobem przechowywania informacji), która przechowuje wszystkie informacje o pliku (np. jego rozmiar, uprawnienia dostępu, kiedy został utworzony i gdzie znajduje się w systemie) z wyjątkiem jego nazwy (nazw) i jego rzeczywistych danych. Fakt, że numery inode są unikalne tylko w obrębie dowolnego systemu plików jest powodem, że nie działają one między systemami plików i partycjami.

Dowiązania twarde są tworzone za pomocą polecenia ln. Na przykład, poniższe polecenie utworzy twardy dowiązanie o nazwie hlink1 do pliku o nazwie file1, oba w bieżącym katalogu (tj. katalogu, w którym użytkownik aktualnie pracuje):

ln file1 hlink1

Gdy tworzone jest twarde dowiązanie, nie ma oczywistego wskazania, że różni się ono od każdego innego pliku. To znaczy, twarde łącza wydają się być plikami tego samego typu, co ich pliki docelowe (tj. pliki, z którymi są połączone), gdy są przeglądane za pomocą poleceń takich jak ls (tj. lista) i file (która jest używana do określania typu określonych plików). Podobnie, gdy oglądane w GUI (graficzny interfejs użytkownika), ikony dla twardych łączy są identyczne z tymi dla ich plików docelowych.

To, że początkowa nazwa pliku i wszystkie twarde łącza do tego pliku wszystkie mają ten sam inode można wyraźnie zobaczyć przy użyciu polecenia ls z jego -i (tj., inode) opcja. Tak więc, na przykład, poniższy tekst pokazuje, że numery inode plików plik1 i hlink1 z powyższego przykładu są identyczne:

ls -i file1 hlink1

Liczba twardych łączy do dowolnego pliku jest pokazana w drugiej kolumnie danych wyjściowych uzyskanych przy użyciu polecenia ls z opcją -l (tzn. long). Widać, że liczba ta jest sumą pliku docelowego i wszystkich twardych łączy do niego (tzn, sumą początkowej nazwy i wszystkich później dodanych nazw) i że jest taka sama dla celu i dla każdego takiego dowiązania.

Pliki z twardymi dowiązaniami można również znaleźć za pomocą polecenia find z opcją -type f (aby wybrać tylko zwykłe pliki), a następnie opcją -links +1 (aby pokazać wszystkie zwykłe pliki z więcej niż jednym twardym dowiązaniem) w następujący sposób:

find -type f -links +1

Gdy zawartość pliku zostanie zmieniona, zachowane zostanie powiązanie ze wszystkimi twardymi dowiązaniami. Jednak niektóre edytory tekstu mogą zerwać to powiązanie, tworząc nowy inode dla zmienionej zawartości,1 a zatem rozsądne może być sprawdzenie ważnych powiązań po modyfikacji plików.

Polecenie rm powierzchownie wydaje się usuwać lub kasować pliki. Jednak to, co naprawdę robi, to zmniejszenie liczby twardych odnośników pliku (tj. liczby nazw, które plik posiada) o jeden, i nie wpływa bezpośrednio na inode lub dane pliku. Kiedy liczba ta osiągnie zero, wydaje się, że plik zniknął, ponieważ nie ma już żadnego prostego sposobu na odwołanie się do niego. Jednak dane pliku są naprawdę usuwane tylko wtedy, gdy miejsce(a) na dysku twardym (HDD) lub innym nośniku pamięci, które go zawiera, zostanie nadpisane przez nowy plik.

Tak więc, na przykład, następujące czynności usunęłyby twarde łącze hlink1, które zostało utworzone w powyższym przykładzie:

rm hlink1

Ponowne użycie rm z jedną pozostałą nazwą, jak poniżej, spowodowałoby, że dane pliku stałyby się praktycznie niedostępne:

rm file1

Prawdopodobnie najbardziej użytecznym zastosowaniem twardych łączy jest umożliwienie plikom, programom i skryptom (tj.tj. krótkie programy), aby być łatwo dostępne w innym katalogu niż oryginalny plik lub plik wykonywalny (tj, gotowej do uruchomienia wersji programu). Wpisanie nazwy twardego łącza spowoduje, że program lub skrypt zostanie wykonany w taki sam sposób, jak przy użyciu jego oryginalnej nazwy.

Dowiązania symboliczne, zwane też miękkimi, są bardziej użyteczne niż twarde, ponieważ można je tworzyć zarówno do katalogów, jak i do plików w różnych systemach plików i na różnych partycjach. Ponadto, podczas korzystania z GUI, dowiązania symboliczne mają specjalne ikony, które natychmiast identyfikują je jako dowiązania, a nie zwykłe pliki. Mają one jednak tę wadę, że stają się bezużyteczne, jeśli ich plik docelowy zostanie usunięty.

Aliasy powierzchownie przypominają dowiązania twarde w tym sensie, że są kolejnym sposobem podawania wielu nazw dla dowolnego pliku. Jednakże, polecenie aliasu jest wbudowane w powłokę (tj. program zapewniający tekstowy interfejs użytkownika), a nie jest osobnym programem, a mechanizm jest zupełnie inny niż w przypadku twardych odnośników. Podobnie jak dowiązania symboliczne, aliasy mogą być używane nie tylko dla plików, ale również dla katalogów i mogą przekraczać granice systemów plików i partycji. Ponadto, alias może być użyty jako skrócona nazwa dowolnego tekstu powłoki (tj. polecenia lub serii połączonych poleceń, łącznie z ich opcjami i/lub argumentami).

________
1Testy na Red Hat Linux 9 wykazały, że dowiązania twarde były łamane podczas modyfikowania plików przy użyciu edytora tekstu gedit. Jednakże nie były one łamane podczas używania edytorów tekstowych vi i Abiword, jak również edytora heksadecymalnego KHexEdit na tej samej wersji Linuksa. Niepowodzenie gedit w zachowaniu twardych linków wynikało z faktu, że w rzeczywistości tworzy on kopię zmodyfikowanego pliku, którą zapisuje (i stąd nowy numer inode), zamiast wprowadzać zmiany w oryginalnym pliku, ale ta kopia otrzymuje nazwę oryginalnego pliku. Jednak podobny test przy użyciu nowszej wersji gedit (2.14.0) na Fedora Core 5 wykazał, że problem został poprawiony i nie doszło do zerwania linków.