Proč v systému UNIX / Linux nejsou povoleny pevné odkazy na adresáře?

To je jen špatný nápad, protože neexistuje způsob, jak poznat rozdíl mezi pevným odkazem a původním názvem.

Povolení pevných odkazů do adresářů by narušilo směrovanou acyklickou grafickou strukturu souborového systému, což by mohlo vytvořit smyčky adresářů a visící podstromy adresářů, což by udělá fsck a jakékoli jiné chodce stromů souborů náchylné k chybám.

Nejprve, abychom tomu porozuměli, promluvme si o inodech. Data v souborovém systému jsou uložena v bloky na disku a tyto bloky jsou shromažďovány společně inodem. Můžete si představit inode jako THE THE. Inodes však nemají názvy souborů. Odtud přicházejí odkazy.

Odkaz je pouze ukazatel na inodu. Adresář je inode, který obsahuje odkazy. Každý název souboru v adresáři je pouze odkazem na inode. Otevření souboru v Unixu také vytvoří odkaz, ale je to jiný typ odkazu (nejedná se o pojmenovaný odkaz).

Pevný odkaz je jen další položka adresáře ukazující na tento inode. Když ls -l, číslo za oprávněními je počet pojmenovaných odkazů. Většina běžných souborů bude mít jeden odkaz. Vytvoření nového pevného odkazu na soubor způsobí, že oba názvy souborů budou směřovat ke stejnému inodu. Poznámka:

% ls -l test ls: test: No such file or directory % touch test % ls -l test -rw-r--r-- 1 danny staff 0 Oct 13 17:58 test % ln test test2 % ls -l test* -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 % touch test3 % ls -l test* -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3 ^ ^ this is the link count 

Nyní můžete jasně vidět, že neexistuje žádný pevný odkaz. Pevný odkaz je stejný jako běžný název. Ve výše uvedeném příkladu, test nebo test2, který je původním souborem a který je pevným odkazem? Na konci to nebudete vědět (ani podle časových značek), protože obě jména ukazují na stejný obsah, stejný inode:

% ls -li test* 14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test 14445750 -rw-r--r-- 2 danny staff 0 Oct 13 17:58 test2 14445892 -rw-r--r-- 1 danny staff 0 Oct 13 17:59 test3 

-i příznak ls zobrazí čísla inode na začátku řádku. Všimněte si, jak test a test2 mají stejné číslo inodu, ale test3 má jiné.

Nyní, pokud vám bylo dovoleno udělejte to pro adresáře, dva různé adresáře v různých bodech souborového systému by mohly ukazovat na stejnou věc. Ve skutečnosti by subdir mohl ukázat zpět na svého prarodiče a vytvořit smyčku.

Proč je tato smyčka znepokojující ? Protože když procházíte, neexistuje žádný způsob, jak zjistit, že procházíte smyčkou (aniž byste sledovali počet inodů při procházení). Představte si, že píšete příkaz du, který musí rekurzujte prostřednictvím subdirů a zjistěte informace o využití disku. Jak by du věděl, kde n zasáhlo smyčku? Je to náchylné k chybám a spousta účetnictví, které by du musel udělat, jen aby stáhl tento jednoduchý úkol.

Symlinks jsou úplně jiné zvíře, v že se jedná o speciální typ „souboru“, který má mnoho API souborového systému tendenci automaticky následovat. Symbolický odkaz může odkazovat na neexistující cíl, protože směřuje podle názvu, a nikoli přímo na inode. Tento koncept nedává smysl u pevných odkazů, protože pouhá existence „pevného odkazu“ znamená, že soubor existuje.

Proč se tedy du vypořádat Symlinks snadno a ne tvrdé odkazy? Výše jsme viděli, že pevné odkazy jsou k nerozeznání od běžných položek adresáře. Symlinks jsou však speciální, zjistitelné a přeskočitelné! du si všimne, že symbolický odkaz je symbolický odkaz a zcela jej přeskočí!

% ls -l total 4 drwxr-xr-x 3 danny staff 102 Oct 13 18:14 test1/ lrwxr-xr-x 1 danny staff 5 Oct 13 18:13 test2@ -> test1 % du -ah 242M ./test1/bigfile 242M ./test1 4.0K ./test2 242M . 

Komentáře

• Allowing hard links to directories would break the directed acyclic graph structure of the filesystem.Můžete mi prosím vysvětlit více o problému s cykly pomocí pevných odkazů? Proč je to v pořádku se symbolickými odkazy
• Zdá se, že to na počítačích Mac povolili přidáním detekce cyklu do systémového volání link () a odmítnutím povolit vytvoření pevného odkazu adresáře, pokud by to vytvořilo cyklus . Zdá se být rozumným řešením.
• @psusi mkdir -p a / b; nocheckln ca; mv c a / b; – nocheckln existuje teoretický ln, který nekontroluje adresářové args a jen předá odkaz, a protože nedochází k žádnému cyklu, jsme všichni dobří ve vytváření ‚ c ‚. pak přesuneme ‚ c ‚ do ‚ a / b ‚ a cyklus je vytvořen z / b / c – > a / – kontrola v odkazu () není dost dobrá
• Cykly jsou velmi špatné. Windows mají tento problém s “ křižovatkami „, což jsou adresáře pevných odkazů. Pokud omylem použijete oprávnění na celý svůj profil, odhalí řadu spojů, které vytvářejí nekonečný cyklus. Opakování v adresářích se opakuje, dokud to nezastaví omezení délky cesty.
• @WhiteWinterWolf, podle tohoto odkazu konkrétně přidali jeho podporu pro stroj času, ale může to dělat pouze root: superuser.com/questions/360926/…

Pomocí příkazu bind mount můžete simulovat adresáře s pevným odkazem

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory sudo umount /else/dummy_but_existing_directory 

S výjimkou přípojných bodů má každý adresář jednoho nadřazeného: ...

Jeden způsob, jak pwd zkontrolovat zařízení: inode na „.“ a „..“. Pokud jsou stejné, dostali jste se do kořenového adresáře systému souborů. V opačném případě najděte název aktuálního adresáře v nadřazené položce, vložte jej do zásobníku a začněte porovnávat „../.“ s „../ ..“, poté „../../.“ s „../../ ..“ atd. Jakmile narazíte na kořen, začněte objevovat a tisknout jména ze zásobníku. Tento algoritmus se spoléhá na skutečnost, že každý adresář má jednoho a pouze jednoho rodiče.

Pokud byly povoleny pevné odkazy na adresáře, na kterého z několika rodičů by měl .. odkazovat? To je jeden přesvědčivý důvod, proč pevné odkazy na adresáře nejsou povoleny.

Odkazy na adresáře nezpůsobují tento problém. Pokud program chce, může provést lstat() v každé části názvu cesty a zjistit, kdy se vyskytne symbolický odkaz. Algoritmus pwd vrátí skutečnou absolutní cestu k cílovému adresáři. Skutečnost, že někde je text (symbolický odkaz), který ukazuje na cílový adresář, je do značné míry irelevantní. Existence takového symbolického odkazu nevytváří v grafu smyčku.

Komentáře

• Tím si nejsem tak jistý. Pokud si myslíme, že .. je jakýmsi virtuálním pevným odkazem na rodiče, neexistuje žádný technický důvod, aby cíl odkazu mohl mít pouze jeden další odkaz. pwd by k vyřešení cesty musel použít jiný algoritmus.

Rád bych k této otázce přidal několik dalších bodů. Pevné odkazy pro adresáře jsou v linuxu povoleny, ale omezeným způsobem.

Jedním ze způsobů, jak to můžeme otestovat, je to, že když uvedeme obsah adresáře, najdeme dva speciální adresáře „.“ a „..“. Jak víme „.“ odkazuje na stejný adresář a „..“ odkazuje na nadřazený adresář.

Umožňuje tedy vytvořit strom adresářů, kde „a“ je nadřazený adresář, který má jako podřízený adresář „b“.

 a `-- b 

Poznamenejte si inode adresáře „a“. A když provedeme ls -la z adresáře „a“, můžeme to vidět „.“ adresář také ukazuje na stejný inode.

797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 a 

A zde zjistíme, že adresář „a“ má tři pevné odkazy. Je to proto, že inode 797358 má tři pevné odkazy ve jménu „.“ uvnitř adresáře „a“ a názvu jako „..“ uvnitř adresáře „b“ a jednoho s názvem „a“ itlef.

$ ls -ali a/ 797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 . $ ls -ali a/b/ 797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 .. 

Takže zde můžeme rozumět že pevné odkazy jsou tu pro adresáře pouze pro připojení k jejich nadřazeným a podřízeným adresářům. A tak adresář bez potomka bude mít pouze 2 pevné odkazy, takže adresář „b“ bude mít pouze dva pevné odkazy.

Jedním z důvodů, proč bylo zabráněno volnému pevnému propojení adresářů, by bylo vyhnout se nekonečným referenčním smyčkám, které zamění programy, které procházejí souborovým systémem.

Protože je souborový systém organizován jako strom a protože strom nemůže mít cyklický odkaz, mělo by se tomu zabránit.

Komentáře

• Dobrý příklad. Vyčistilo to mé pochybnosti. Tyto případy jsou tedy řešeny zvláštním způsobem, aby se zabránilo nekonečným smyčkám. že jo?
• Protože máme omezený způsob povolování pevných odkazů pro adresáře, tj. “ .. “ a „. “ nedosáhneme nekonečné smyčky, a proto bychom nevyžadovali žádné zvláštní způsoby, jak se jim vyhnout, protože k nim nedojde:)

Žádný z následujících důvodů není skutečným důvodem pro zakázání pevných odkazů na adresáře; každý problém je poměrně snadné vyřešit:

• cykly ve stromové struktuře způsobují obtížné procházení
• více rodičů, takže který je ten „skutečný“?
• sběr odpadků souborového systému

skutečný důvod (jak naznačuje @ Thorbjørn Ravn Andersen) přijde, když smažete adresář, který má více rodičů, z adresáře, na který ukazuje ..:

Na co by měl .. nyní odkazovat?

Pokud je adresář odstraněn z nadřazeného objektu, ale počet jeho odkazů je je stále větší než 0, pak tam něco musí být, někde to stále ukazuje. Nemůžete opustit .. ukazující na nic; mnoho programů se spoléhá na .., takže systém by musel projít celý souborový systém , dokud nenajde první věc, která odkazuje na odstraněný adresář, stačí aktualizovat ... Buď to, nebo by systém souborů musel udržovat seznam všechny adresáře odkazující na pevně propojený adresář.

V každém případě by to bylo režie výkonu a další komplikace pro metadata a / nebo kód systému souborů, takže se návrháři rozhodli to nepovolit.

Komentáře

• To je ‚ také snadné vyřešit: vést seznam rodičů podřízeného adresáře, kterou aktualizujete, když přidáte nebo odeberete odkaz na dítě. Když odstraníte kanonického rodiče (cíl dítěte ‚ s

  ), aktualizujte .. tak, aby ukazoval na jednoho z dalších rodičů v seznamu.

• Souhlasím. Není to raketová věda k řešení. Ale přesto výkonnostní režie a zabralo by to trochu více místa v meta datech systému souborů a přidalo by to komplikace. A tak se návrháři rozhodli pro jednoduchý a rychlý přístup – neumožňujte ‚ odkazy na tvrdé adresáře.
• Sym odkazy na dirs “ porušují ustálenou sémantiku a chování „, přesto jsou stále povoleni. Některé příkazy proto potřebují možnosti, aby bylo možné řídit, zda jsou dodržovány odkazy na symboly (např. -L v find a cp). Když program následuje ‚ .. ‚ je zde další zmatek, proto rozdíl ve výstupu z pwd a / bin / pwd po projetí symbolický odkaz. “ Unixové odpovědi “ neexistují; jen designová rozhodnutí. Toto se točí kolem toho, co se stane s “ .. „, jak jsem uvedl ve své odpovědi. Bohužel ‚ .. ‚ není v odpovědi uveden ani jeden div, že všichni ostatní tak ostýchavě hlasuje pro.
• BTW, ‚ neříkám, že jsem ‚ m ve prospěch pevných odkazů na dirs. Vůbec ne. Nechci ‚ nechci, aby moje denní práce byla těžší, než již je.
• To ‚ není to, co POSIX říká, ale IMO ‚ .. ‚ nikdy neměl být konceptem souborového systému, spíše syntakticky vyřešen na cestách, takže a/.. by vždy znamenalo .. Takto fungují adresy URL, btw. ‚ s prohlížečem ‚ s řešením ‚ .. ‚ ještě předtím, než narazí na server. A funguje to skvěle.

Vytváření pevných odkazů v adresářích by bylo nevratné. Předpokládejme, že máme:

/dir1 ├──this.txt ├──directory │ └──subfiles └──etc 

Pevně jej propojím s /dir2.

Takže /dir2 nyní také obsahuje všechny tyto soubory a adresáře

Co když si to rozmyslím? Nemohu jen rmdir /dir2 (protože není prázdný)

A pokud rekurzivně odstraním /dir2. .. bude smazán také z /dir1!

IMHO je převážně dostatečný důvod, proč tomu zabránit!

Upravit:

Komentáře navrhují odstranění adresáře provedením rm .Ale rm na neprázdném adresáři selže a toto chování musí zůstat, ať už je adresář pevně propojen nebo ne. Takže jej nemůžete rm odpojit. Vyžadovalo by to nový argument rm, stačí říct „pokud je adresář inode“ má počet odkazů> 1, pak pouze zruší propojení adresáře „.

Což zase prolomí další princip nejmenšího překvapení: znamená to, že odstranění hardlinku adresáře, který jsem právě vytvořil, není totéž jako odstranění normálního pevného odkazu na soubor …

Přeformuluji svou větu: Bez dalšího vývoje by bylo vytvoření pevného odkazu nevratné (protože žádný aktuální příkaz by nemohl zvládnout odebrání, aniž by byl v rozporu s aktuálním chováním)

Pokud povolíme další vývoj případu, počet nástrah a riziko ztráty dat pokud „nejsme si dostatečně vědomi toho, jak systém funguje, jak naznačuje takový vývoj, je IMHO dostatečným důvodem k omezení odkazů na adresáře.

Komentáře

• To by neměl být problém. Ve vašem případě, když vytváříme pevný odkaz na dir2, musíme vytvořit pevný odkaz na veškerý obsah v dir1, takže pokud přejmenujeme nebo odstraníme dir2, smaže se pouze další odkaz na inode. A to by nemělo ovlivnit dir1 a jeho obsah, protože existuje alespoň jeden odkaz (dir1) na inode.
• Váš argument je nesprávný. Jednoduše jej odpojíte, neuděláte rm -rf. A pokud počet odkazů dosáhne 0, systém by věděl, že může také smazat veškerý obsah.
• To ‚ je víceméně vše rm stejně funguje (odpojit). Viz: unix.stackexchange.com/questions/151951/… To opravdu není ‚ Není to problém, o nic víc než u souborů s pevným odkazem. Odpojení pouze odstraní pojmenovanou referenci a sníží počet odkazů. Skutečnost, že rmdir nevyhraje ‚ smazání neprázdných adresářů, je irelevantní – to by ‚ To neděláme ani pro dir1. Hardlinky nejsou ‚ t kopií dat, jsou to stejný skutečný soubor, proto “ mazání “ soubor dir2 vymaže výpis adresáře pro dir1. Vždy byste museli zrušit propojení.
• Nelze jej ‚ jednoduše odpojit jako normální soubor, protože rm v adresáři don ‚ t jej neodpojit, pokud ‚ není prázdný. Viz Úpravy.

Toto je dobré vysvětlení. Ohledně „Na kterého z více rodičů by měl .. ukázat?“ jedním z řešení by bylo, kdyby si proces udržoval svou úplnou cestu wd, ať už jako inody nebo jako řetězec. inody by byly robustnější, protože názvy lze měnit. Alespoň v dávných dobách existoval inode jádro pro každý otevřený soubor, který byl zvýšen při každém otevření souboru, snížen při zavření. Když dosáhne nuly, uvolní se i úložiště, na které ukazuje. Když už soubor nikdo neotevřel, byl (kopie jádra) opuštěn. To by udržovalo cestu jako platnou, pokud nějaký jiný proces přesunul adresář do jiného adresáře, zatímco podadresář byl v cestě jiného procesu. Podobně jako můžete odstranit otevřený soubor, ale je jednoduše odstraněn z adresáře, ale stále otevřen pro všechny procesy, které jej mají otevřené.

Adresáře s pevným odkazem bývaly v Bell Labs UNIX volně povoleny, alespoň V6 a V7, nevíte o Berkeley nebo novějších. Není vyžadována vlajka. Mohli byste vytvořit smyčky? Ano, nedělejte to. Je zcela jasné, co děláte, pokud vytvoříte smyčku. Nether byste si měli procvičovat vázání uzlů kolem krku, zatímco čekáte, až na vás přijde řada na seskoky z letadla, pokud máte druhý konec pohodlně zavěšený na háku na hlavě.

Co Doufal jsem, že to dnes udělám s hard-link lhome to home, abych mohl mít / home / administ k dispozici bez ohledu na to, zda / home byl zakryt automatem přes domov, který automount měl symbolický odkaz s názvem administ do / lhome / administ. To mi umožňuje mít účet správce, který funguje bez ohledu na stav mého primárního domovského souborového systému. Toto JE experiment pro linux, ale myslím, že najednou jsem se naučil pro SunOS založený na UCB, že automatické připojení se provádí na úrovni řetězce ascii. Je těžké pochopit, jak by se jich dalo jinak dosáhnout jako vrstvy nad libovolným FS.

Četl jsem to jinde. a .. již nejsou soubory v adresáři. Jsem si jist, že k tomu všemu existují dobré důvody a že mnoho z toho, co nás baví (například možnost připojení NTFS), je kvůli těmto věcem možné, ale v implementaci byla jistá elegance systému UNIX.Díky výhodám jako je obecnost a tvárnost, které tato elegance poskytla, jí umožnila být tak robustní a vydržet po čtyři desetiletí. Jakmile uvolníme elegantní implementace, nakonec to bude jako Windows (doufám, že se mýlím!). Někdo by pak vytvořil nový OS, který je založen na elegantních principech. O čem přemýšlet. Možná se mýlím, nejsem (samozřejmě) obeznámen se současnou implementací. Je úžasné, jak použitelné je 30leté porozumění systému Linux … většinou!

Komentáře

• Myslím si, že i když se můžu mýlit, že . a .. nejsou pro moderní souborové systémy hardwarové odkazy v souborovém systému. Ovladač systému souborů je však předstírá. Jsou to tyto systémy souborů, které zastavují tvrdé propojení adresářů. U starých souborových systémů to bylo možné (ale nebezpečné). Chcete-li dělat to, co zkoušíte, podívejte se na mount --bind, podívejte se také na mount --make… a možná na kontejnery.

Z toho, co jsem shromáždil, je hlavním důvodem to, že je užitečné mít možnost měnit názvy adresářů, aniž by došlo ke zmatení spuštěných programů, které používají jejich pracovní adresář k odkazování na jiné soubory. Předpokládejme, že jste ke spuštění ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe používali Wine a chtěli byste místo toho přesunout celou předponu na ~/.wine. Pokud Firefox z nějakého zvláštního důvodu přistupoval k drive_c/windows odkazem na ../../windows, přejmenovával ~/.newwineprefix přestávky implementace .., které sledují nadřazený adresář jako textový řetězec namísto inodu.

Ukládání inodu jednoho nadřazeného adresáře musí být jednodušší než zkoušet sledovat každou cestu jako textový řetězec i řadu inodů.

Dalším důvodem je, že misbehavi ng aplikace mohou být schopny vytvářet smyčky. Chované aplikace by měly být schopny zkontrolovat, zda je inode adresáře, který se přesouvá, stejný jako inode kteréhokoli z vnořených adresářů, do kterých se přesouvá, stejně jako nemůžete přesunout adresář do sebe, ale toto nemusí být vynucováno na úrovni souborového systému.

Dalším důvodem může být to, že pokud byste mohli vytvořit pevné odkazy v adresářích, chtěli byste zabránit pevnému propojení v adresáři, který byste nemohli upravit. find má bezpečnostní úvahy, protože se používá k vymazání souborů vytvořených jinými uživateli z dočasných adresářů, což může způsobit problémy, pokud uživatel přepne skutečný adresář na symbolický odkaz, zatímco find vyvolává jiný příkaz. Možnost pevného propojení důležitých adresářů by správce přinutila přidat do find další testy, aby se jich nedotkly. (Ok, už to pro soubory nelze, takže tento důvod je neplatný.)

Dalším důvodem je, že uložení inodu nadřazeného adresáře může poskytnout další redundanci v případě poškození nebo poškození systému souborů. chtěl .. vypsat všechny nadřazené adresáře, které pevně odkazují na tento, takže je možné snadno najít jiného, libovolného rodiče, pokud je aktuální vypuštěn, nejen že porušujete myšlenku, že odkazy jsou stejné, musíte změnit způsob, jakým souborový systém ukládá a používá inody. Mít programy považovat cesty za sérii (uniq každý hardlink) adresářových inodů by se tomu vyhnul, ale v případě poškození systému souborů byste nedostali redundanci.