Czy istnieją systemy plików, dla których `ln -d` się powiedzie?

11

Z strony podręcznika dla ln :

-d, -F, --directory
  allow the superuser to attempt to hard link directories (note: will 
  probably fail due to system restrictions, even for the superuser)

Czy są jakieś sterowniki systemu plików, które faktycznie na to pozwalają, czy też jest to jedyna opcja mount --bind <src> <dest>? Czy też takie zachowanie jest blokowane przez jądro, zanim dotrze ono do sterownika specyficznego dla systemu plików?

UWAGA: Tak naprawdę nie planuję tego robić na żadnych maszynach, po prostu jestem ciekawy.

Parthian Shot
źródło

Odpowiedzi:

6

Najpierw uwaga: lnkomenda nie posiada opcje takie jak -d, -F, --directory, to jest non-przenośny GNUism.

Funkcja, której szukasz, została zaimplementowana przez link(1)polecenie.

Powrót do pierwotnego pytania:

W typowym systemie UNIX decyzja, czy możliwe są twarde dowiązania do katalogów, podejmowana jest w sterowniku systemu plików.

Sterownik Solaris UFS obsługuje twarde łącza w katalogach, sterownik ZFS nie obsługuje.

Powodem, dla którego UFS w systemie Solaris obsługuje twarde łącza, jest to, że AT&T była zainteresowana tą funkcją - UFS z BSD nie obsługuje katalogów z twardymi linkami.

Powodem, dla którego ZFS nie obsługuje katalogów podlinkowanych jest to, że Jeff Bonwick nie lubi tej funkcji.

Jeśli chodzi o Linuksa, zgaduję, że Linux blokuje próby utworzenia twardych dowiązań w katalogach w wyższych warstwach jądra. Powodem tego założenia jest to, że Linus Torvalds napisał kod dla GIT, który zniszczył katalogi, gdy git clonezostał wywołany jako root na platformie, która obsługuje twardo połączone katalogi.

Należy pamiętać, że system plików, który obsługuje tworzenie twardo połączonych katalogów, musi również obsługiwać unlink(1)usuwanie niepustych katalogów jako root.

Więc jeśli założymy, że Torvalds wie, jak działa Linux i jeśli Linux obsługiwał twardo połączone katalogi, Torvalds powinien był wiedzieć, że wywołanie unlink(2)katalogu będąc rootem, nie powróci z błędem, ale zniszczy ten katalog. Innymi słowy, jest mało prawdopodobne, aby Linux zezwalał sterownikowi systemu plików na implementowanie twardych dowiązanych katalogów.

schily
źródło
3

Pytanie OP wspomina mount --bind. Szybkie sprawdzenie pokazuje, że nie modyfikuje licznika dowiązań dla zamontowanego katalogu. Twarde linkowanie zawsze modyfikuje liczbę linków, które można zobaczyć za pomocą ls -ld.

Zwykle (większość systemów uniksowych) liczba dowiązań twardych do katalogu będzie liczbą katalogów podłączonych do tej nazwy, np.

  • ".." (katalog nadrzędny)
  • "." (sam katalog)
  • podkatalogi

Jeśli przeczytasz (zwykle) bardziej informacyjną stronę informacyjną , możesz odkryć tak jak inni :

Oh great, one spends hours tying to find what is wrong only to
discover,
$ info ln
On all existing implementations, you cannot make a hard link to a
directory, and hard links cannot cross filesystem boundaries.  (These
restrictions are not mandated by POSIX, however.)

Therefore, kindly say everywhere you say super-user only,
instead say "few systems, super-user only".

choć obecnie jest sformułowany

Większość systemów zabrania tworzenia twardego łącza do katalogu; na tych, gdzie jest to dozwolone, tylko superużytkownik może to zrobić (i ostrożnie, ponieważ tworzenie cyklu spowoduje problemy dla wielu innych narzędzi). Twarde łącza nie mogą przekraczać granic systemu plików. (Te ograniczenia nie są jednak wymagane przez POSIX).

Tworzenie (i usuwanie) twardych dowiązań do katalogu jest ograniczoną funkcją chroniącą przed utratą plików w przypadku rozłączenia katalogu. Ponieważ operacje link / unlink na interfejsie systemu operacyjnego C są symetryczne , połączenie z katalogami zwykle odbywa się tylko w wywołaniach mkdir / rmdir.

Należy pamiętać, że wiele rdzeni GNU zostało napisanych (i udokumentowanych) 20-30 lat temu, kiedy niektóre prawdziwe dzieła muzealne były nadal w użyciu. Jak zauważono w odniesieniu do Hard Link , pierwotnie nie było wywołań mkdir / rmdir; katalogi zostały utworzone (jako operacja uprzywilejowana) przy użyciu twardych łączy. Wszystko to minęło, gdy dodano wywołania systemowe w celu rozwiązania wspomnianych problemów. Ale dokumentacja nadal odnosi się do tych systemów, które przeszły pamięć ich opiekunów. Opcji, który jest w wątpliwość poprzednika fileutils(który w połączeniu z textutils, a shellutilsw połowie lat 1990-tych w celu wytworzenia coreutils). Kilka elementów z dziennika zmian może pomóc wyjaśnić pochodzenie funkcji:

Mon Jul 23 16:57:44 1990  David J. MacKenzie  (djm at albert.ai.mit.edu)

        * cp.c (copy): Make +update operate silently, like +one-file-system.
        * ln.c: Add -F as synonym for -d, for SunOS compatibility.

Wed Feb 21 11:13:26 1990  David J. MacKenzie  (djm at albert.ai.mit.edu)

        * ln.c (error): New function.
        (main, do_link): Call error instead of fprintf and exit. 
        (main): Recognize new -d +directory option to allow superuser to
        make hard links to dirs, like the BSD ln -f option.
        (do_link): Don't allow hard links to dirs (they are hard to
        get rid of -- rmdir and unlink don't do it), unless -d was given.
        (usage): Mention -d +directory option.

Możesz więc zobaczyć na przykład, że jednym z antyków, dla których ta funkcja miała zastosowanie, był SunOS. Odpowiednia strona podręcznika powiedziała:

OPTIONS
       -f     Force a hard link to a directory -- this option is  only   avail-
              able to the super-user.

       -s     Create a symbolic link or links.

SYSTEM V OPTIONS
       -f     Force  files to be linked without displaying permissions, asking
              questions or reporting errors.

       -F     Force a hard link to a directory -- this option is  only  avail-
              able to the super-user.

       -s     Create a symbolic link or links.

Jak zauważono w dokumentacji, ta funkcja (i odpowiadająca jej opcja nie są w POSIX (i zobacz sekcję Uzasadnienie, która wyjaśnia, dlaczego). Zamiast tego funkcja została przeniesiona do nowej komendy (udostępnionej również przez coreutils GNU) link. Opis samo polecenie jest niejasne; należy przeczytać opis wywołania funkcji, aby uzyskać jakikolwiek użytek ze standardu, jednak standard nie wyjaśnia warunków, w których polecenie będzie działać, oprócz przekazywania wyłączenia odpowiedzialności na temat wymaganych uprawnień. W tym celu musisz przejść do funkcji zależnych od systemu poza standardem:

Łączenie z katalogiem jest ograniczone do administratora w większości historycznych implementacji, ponieważ ta funkcja może powodować powstawanie pętli w hierarchii plików lub w inny sposób uszkodzić system plików. Ten tom POSIX.1-2008 kontynuuje tę filozofię, zabraniając link()i unlink()robienia tego. Inne funkcje mogłyby to zrobić, jeśli implementator zaprojektował takie rozszerzenie.

Tam systemy wykorzystujące hardlinki do katalogów poza numerem normalnej (2 plus podkatalogów).

OSX używa wielu dowiązań twardych do katalogów zwykłych plików . Nie obsługuje tego przy użyciu ln(patrz strona instrukcji ). Zgodnie z tym, jak Time Machine działa swoją magią , robi to w celu zapewnienia wersji używanych do tworzenia kopii zapasowych Time Machine.

Dalsza lektura:

Thomas Dickey
źródło
3
To wcale nie odpowiada na pytanie.
Michael Homer