Używam Ubuntu 12.04. Kiedy próbuję utworzyć twardy link do dowolnego katalogu, to się nie udaje. Mogę tworzyć twarde linki do plików w granicach systemu plików. Znam powód, dla którego nie możemy tworzyć dowiązań twardych dla plików poza systemem plików.

Próbowałem tych poleceń:

$ ln /Some/Direcoty /home/nischay/Hard-Directory
hard link not allowed for directory
$ sudo ln /Some/Direcoty /home/nischay/Hard-Directory
[sudo] password for nischay: 
hard link not allowed for directory

Chcę tylko poznać przyczynę tego. Czy to samo dotyczy wszystkich dystrybucji GNU / Linux i odmian uniksowych (BSD, Solaris, HP-UX, IBM AIX), czy tylko w Ubuntu lub Linux?

Dowiązania twarde katalogów niszczą system plików na wiele sposobów

Pozwalają tworzyć pętle

Twarde łącze do katalogu może prowadzić do samego rodzica, który tworzy pętlę systemu plików. Na przykład te polecenia mogą utworzyć pętlę z łączem zwrotnym l:

mkdir -p /tmp/a/b
cd /tmp/a/b
ln -d /tmp/a l

System plików z pętlą katalogów ma nieskończoną głębokość:

cd /tmp/a/b/l/b/l/b/l/b/l/b

Unikanie nieskończonej pętli podczas przechodzenia przez taką strukturę katalogów jest nieco trudne (chociaż na przykład POSIX wymaga findtego).

System plików z tego rodzaju twardym łączem nie jest już drzewem, ponieważ drzewo nie może z definicji zawierać pętli.

Przełamują jednoznaczność katalogów nadrzędnych

W pętli systemu plików istnieje wiele katalogów nadrzędnych:

cd /tmp/a/b
cd /tmp/a/b/l/b

W pierwszym przypadku /tmp/ajest katalogiem nadrzędnym /tmp/a/b.
W drugim przypadku /tmp/a/b/lkatalog nadrzędny /tmp/a/b/l/bjest taki sam jak /tmp/a/b.
Ma więc dwa katalogi nadrzędne.

Mnożą pliki

Pliki są identyfikowane przez ścieżki, po rozwiązaniu dowiązań symbolicznych. Więc

/tmp/a/b/foo.txt
/tmp/a/b/l/b/foo.txt

to różne pliki.
Istnieje nieskończenie wiele innych ścieżek do pliku. Są one oczywiście takie same pod względem liczby i-węzłów. Ale jeśli nie oczekujesz wyraźnie pętli, nie ma powodu, aby to sprawdzać.

Twarde łącze do katalogu może również wskazywać na katalog podrzędny lub katalog, który nie jest ani dzieckiem ani rodzicem żadnej głębokości. W takim przypadku plik będący dzieckiem łącza zostanie zreplikowany do dwóch plików, identyfikowanych przez dwie ścieżki.

Twój przykład

$ ln /Some/Direcoty /home/nischay/Hard-Directory
$ echo foo > /home/nischay/Hard-Directory/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ echo bar >> /Some/Direcoty/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ cat /Some/Direcoty/foobar.txt
foo
bar

Jak zatem mogą działać miękkie linki do katalogów?

Ścieżka, która może zawierać softlinki, a nawet miękkie pętle katalogów, jest często używana tylko do identyfikacji i otwarcia pliku. Można go wykorzystać jako normalną ścieżkę liniową.

Istnieją jednak inne sytuacje, w których ścieżki są używane do porównywania plików. W takim przypadku dowiązania symboliczne na ścieżce można najpierw rozwiązać, przekształcając je w minimalną i powszechnie uzgodnioną reprezentację, tworząc ścieżkę kanoniczną :

Jest to możliwe, ponieważ wszystkie miękkie linki można rozwinąć do ścieżek bez łącza. Po zrobieniu tego ze wszystkimi miękkimi linkami na ścieżce, pozostała ścieżka jest częścią drzewa, gdzie ścieżka jest zawsze jednoznaczna.

Polecenie readlinkmoże rozwiązać ścieżkę do ścieżki kanonicznej:

$ readlink -f /some/symlinked/path

Miękkie linki różnią się od tego, z czego korzysta system plików

Miękkie łącze nie może powodować wszystkich problemów, ponieważ różni się od łączy w systemie plików. Można go odróżnić od twardych łączy i w razie potrzeby przekształcić w ścieżkę bez dowiązań symbolicznych.
W pewnym sensie dodanie dowiązań symbolicznych nie zmienia podstawowej struktury systemu plików - zachowuje ją, ale dodaje więcej struktury, jak warstwa aplikacji.

Od man readlink:

 NAME
        readlink - print resolved symbolic links or canonical
        file names

 SYNOPSIS
        readlink [OPTION]... FILE...

 DESCRIPTION
        Print value of a symbolic link or canonical file name

        -f, --canonicalize
               canonicalize by  following  every  symlink  in
               every component of the given name recursively;
               all but the last component must exist
        [  ...  ]

„Zasadniczo i tak nie powinieneś używać twardych linków” jest zbyt szeroki. Musisz zrozumieć różnicę między dowiązaniami stałymi a dowiązaniami symbolicznymi i używać każdego z nich odpowiednio. Każdy ma własny zestaw zalet i wad:

Łącza symboliczne mogą:

• Wskaż katalogi
• Wskaż nieistniejące obiekty
• Wskaż pliki i katalogi poza tym samym systemem plików

Twarde linki mogą:

• Chroń plik, do którego się odnoszą, przed usunięciem

Twarde linki są szczególnie przydatne przy wykonywaniu aplikacji „kopiuj przy zapisie”. Pozwalają zachować kopię zapasową struktury katalogów, wykorzystując tylko miejsce na pliki, które zmieniają się między dwiema wersjami.

Polecenie cp -aljest szczególnie przydatne w tym względzie. Tworzy kompletną kopię struktury katalogów, w której wszystkie pliki są reprezentowane przez twarde linki do oryginalnych plików. Następnie możesz przystąpić do aktualizacji plików w strukturze, a tylko pliki, które aktualizujesz, zajmą dodatkowe miejsce. Jest to szczególnie przydatne podczas tworzenia kopii zapasowych wielopokoleniowych.

Do Twojej wiadomości możesz osiągnąć to samo, co twarde linki do katalogów, używając mount:

mount -t bind /var/www /home/user/workspace/www

Jest to bardzo niebezpieczne, ponieważ większość narzędzi i programów nie będzie świadoma powiązania . Kiedyś zrobiłem coś jak w powyższym przykładzie, a potem przystąpiłem do rm -rf /home/user. Na szczęście nie było w tym nic istotnego /var/www.

Powód, dla którego twarde linki nie są dozwolone, jest trochę techniczny. Zasadniczo niszczą one strukturę systemu plików . Generalnie nie powinieneś używać twardych linków. Łącza symboliczne pozwalają na większość takich samych funkcji bez powodowania problemów (np ln -s target link.).