Waarom zijn harde links naar mappen niet toegestaan in UNIX / Linux?

Dit is gewoon een slecht idee, aangezien er is geen manier om het verschil te zien tussen een harde link en een originele naam.

Het toestaan van harde links naar mappen zou de gerichte acyclische grafiekstructuur van het bestandssysteem doorbreken, waardoor mogelijk directory-loops en bungelende directory-substructuren ontstaan, wat maak fsck en andere bestandsboomwandelaars vatbaar voor fouten.

Laten we eerst over inodes praten om dit te begrijpen. De gegevens in het bestandssysteem worden bewaard in blokken op de schijf, en die blokken worden bij elkaar verzameld door een inode. Je kunt de inode zien als HET bestand. Inodes hebben echter geen bestandsnamen. Dat is waar links binnenkomen.

Een link is gewoon een wijzer naar een inode. Een directory is een inode die links bevat. Elke bestandsnaam in een directory is slechts een link naar een inode. Het openen van een bestand in Unix creëert ook een link, maar het is een ander type link (het is geen benoemde link).

Een harde link is slechts een extra directory-item dat naar die inode verwijst. Wanneer u ls -l bent, is het nummer achter de machtigingen het benoemde aantal koppelingen. De meeste reguliere bestanden hebben één link. Als u een nieuwe harde link naar een bestand maakt, zullen beide bestandsnamen naar dezelfde inode verwijzen. Opmerking:

% 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 

Nu kun je duidelijk zien dat er niet zoiets bestaat als een harde link. Een harde link is hetzelfde als een gewone naam. In het bovenstaande voorbeeld: test of test2, wat is het originele bestand en wat is de harde link? Aan het einde kun je “het niet echt zeggen (zelfs niet door tijdstempels) omdat beide namen naar dezelfde inhoud verwijzen, dezelfde 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 

De -i markeren naar ls toont u inode-nummers aan het begin van de regel. Merk op hoe test en test2 hebben hetzelfde inode-nummer, maar test3 heeft een ander nummer.

Nu, als je mocht doe dit voor directories, twee verschillende directories op verschillende punten in het bestandssysteem zouden naar hetzelfde kunnen verwijzen. In feite zou een subdir terug kunnen verwijzen naar zijn grootouder en een lus creëren.

Waarom is deze lus een probleem? ? Omdat wanneer u doorkruist, er geen manier is om te detecteren dat u aan het herhalen bent (zonder de inode-nummers bij te houden terwijl u doorkruist). Stel u voor dat u de du -opdracht schrijft, die recurseer via subdirs om meer te weten te komen over schijfgebruik. Hoe zou du weten of n het raakte een lus? Het is foutgevoelig en veel boekhouden dat du zou moeten doen om deze eenvoudige taak uit te voeren.

Symlinks zijn een heel ander beest, in dat ze een speciaal type “bestand” zijn dat veel bestandssysteem-APIs automatisch volgen. Merk op dat een symlink naar een niet-bestaande bestemming kan verwijzen, omdat ze naar naam verwijzen en niet rechtstreeks naar een inode. Dat concept is niet logisch met harde links, want het loutere bestaan van een “harde link” betekent dat het bestand bestaat.

Dus waarom kan du omgaan met symlinks gemakkelijk en geen harde links? We hebben hierboven kunnen zien dat harde links niet te onderscheiden zijn van normale directoryvermeldingen. Symlinks zijn echter speciaal, detecteerbaar en kunnen worden overgeslagen! du merkt op dat de symlink is een symlink, en slaat deze volledig over!

% 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 . 

Reacties

• Allowing hard links to directories would break the directed acyclic graph structure of the filesystem.Kunt u alstublieft meer uitleggen over het probleem met cycli met harde links? Waarom is het ok met symlinks
• Ze lijken het op Macs te hebben toegestaan door cyclusdetectie toe te voegen aan de link () systeemaanroep, en te weigeren je toe te staan een harde directory-link te maken als het een cyclus zou creëren . Lijkt een redelijke oplossing.
• @psusi mkdir -p a / b; nocheckln c a; mv c a / b; – de nocheckln er is een theoretische ln die niet controleert op directory-args, en gewoon doorgaat naar link, en omdat er geen cyclus wordt gemaakt, zijn we allemaal goed in het maken van ‘ c ‘. dan verplaatsen we ‘ c ‘ naar ‘ a / b ‘, en er is een cyclus gemaakt van a / b / c – > a / – inchecken link () is niet goed genoeg
• Cycli zijn erg slecht. Windows heeft dit probleem met ” knooppunten ” die mappen met harde links zijn. Als u per ongeluk machtigingen toepast op uw hele profiel, ontdekt het een reeks knooppunten die een oneindige cyclus creëren. Terugkerend door de mappen wordt herhaald totdat de beperkingen van de padlengte het stoppen.
• @WhiteWinterWolf, volgens deze link, hebben ze specifiek ondersteuning toegevoegd voor de tijdmachine, maar alleen root mag het doen: superuser.com/questions/360926/…

U kunt bind mount gebruiken om hardlinking directories te simuleren

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

Met uitzondering van aankoppelpunten, heeft elke directory één en enige ouder: ...

Een manier om do pwd is om het device: inode te controleren op “.” en “..”. Als ze hetzelfde zijn, hebt u de root van het bestandssysteem bereikt. Zoek anders de naam van de huidige map in de bovenliggende map, druk die op een stapel en begin met het vergelijken van “../.” met “../ ..” en vervolgens “../../.” met “../../ ..”, enz. Zodra je de root hebt geraakt, begin je met het knallen en afdrukken van de namen van de stapel. Dit algoritme is gebaseerd op het feit dat elke directory één en slechts één ouder heeft.

Als harde links naar mappen waren toegestaan, naar welke van de meerdere ouders zou .. dan moeten verwijzen? Dat is een dwingende reden waarom harde links naar mappen niet zijn toegestaan.

Symlinks naar mappen veroorzaken dat probleem niet. Als een programma dat wil, kan het een lstat() uitvoeren op elk deel van de padnaam en detecteren wanneer een symlink wordt aangetroffen. Het pwd -algoritme retourneert de echte absolute padnaam voor een doelmap. Het feit dat er ergens een stukje tekst is (de symlink) dat naar de doelmap verwijst, is vrijwel niet relevant. Het bestaan van een dergelijke symlink creëert geen lus in de grafiek.

Opmerkingen

• Ik ben hier niet zo zeker van. Als we .. beschouwen als een soort virtuele hardlink naar de ouder, is er geen technische reden dat het doel van de link slechts één andere link ernaar kan hebben. pwd zou gewoon een ander algoritme moeten gebruiken om het pad op te lossen.

Ik wil graag nog een paar punten aan deze vraag toevoegen. Harde koppelingen voor mappen zijn toegestaan in linux, maar op een beperkte manier.

Een manier waarop we dit kunnen testen is wanneer we de inhoud van een map weergeven en we twee speciale mappen vinden “.” en “..”. Zoals we weten “.” wijst naar dezelfde directory en “..” verwijst naar de bovenliggende directory.

Laten we dus een directorystructuur maken waarin “a” de bovenliggende directory is met directory “b” als kind.

 a `-- b 

Noteer de inode van directory “a”. En als we een ls -la uit directory “a” doen, kunnen we dat zien. ” directory verwijst ook naar dezelfde inode.

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

En hier kunnen we zien dat de directory “a” drie harde links heeft. Dit komt doordat de inode 797358 drie hardlinks heeft in de naam “.” in “a” directory en naam als “..” in directory “b” en een met naam “a” itslef.

$ 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 .. 

Dus hier kunnen we het begrijpen dat hardlinks er alleen zijn voor mappen om verbinding te maken met hun bovenliggende en onderliggende mappen. En dus zal een directory zonder kind maar 2 hardlink hebben, en dus heeft directory “b” maar twee hardlink.

Een reden waarom het hard linken van directories vrijelijk werd voorkomen, is het vermijden van oneindige referentielussen die zal programmas verwarren die het bestandssysteem doorkruisen.

Aangezien het bestandssysteem is georganiseerd als boom en aangezien de boom geen cyclische referentie kan hebben, had dit vermeden moeten worden.

Opmerkingen

• Goed voorbeeld. Het maakte mijn twijfel weg. Deze gevallen worden dus op een speciale manier afgehandeld om oneindige lussen te vermijden. Rechtsaf?
• Omdat we een beperkte manier hebben om harde links toe te staan voor mappen, dwz ” .. ” en “. ” we zullen geen oneindige lus bereiken en daarom hebben we geen speciale manieren nodig om deze te vermijden, aangezien ze niet zullen gebeuren:)

Geen van de volgende zaken is de echte reden om harde links naar mappen niet toe te staan; elk probleem is redelijk eenvoudig op te lossen:

• cycli in de boomstructuur veroorzaken moeilijk doorlopen
• meerdere ouders, dus welke is de “echte”?
• fileystem garbage collection

De echte reden (zoals gesuggereerd door @ Thorbjørn Ravn Andersen) komt als je verwijdert een map met meerdere ouders, uit de map waarnaar wordt verwezen door ..:

Waar moet .. nu naar verwijzen?

Als de map is verwijderd uit de bovenliggende map maar het aantal links nog steeds groter is dan 0, dan moet er iets zijn, ergens dat er nog steeds naar verwijst. U kunt “.. naar niets laten wijzen; veel programmas vertrouwen op .., dus het systeem zou de volledige bestandssysteem totdat het het eerste vindt dat naar de verwijderde map verwijst, alleen om .. te updaten. Ofwel dat, of het bestandssysteem zou een lijst moeten bijhouden van alle mappen die naar een hard gekoppelde map verwijzen.

Hoe dan ook, dit zou een prestatieoverhead zijn en een extra complicatie voor de metadata en / of code van het bestandssysteem, dus de ontwerpers besloten dit niet toe te staan.

Opmerkingen

• Dat ‘ ook gemakkelijk op te lossen is: houd een lijst bij van de ouders van een onderliggende directory, die u bijwerkt wanneer u een link naar het kind toevoegt of verwijdert. Wanneer u de canonieke ouder verwijdert (het doelwit van het kind ‘ s

  ), update .. om naar een van de andere ouders in de lijst te verwijzen.

• Ik ga akkoord. Geen rocket science om op te lossen. Maar niettemin een prestatie-overhead, en het zou een beetje extra ruimte in de metagegevens van het bestandssysteem in beslag nemen en complicaties toevoegen. En dus gingen de ontwerpers voor de eenvoudige, snelle aanpak – laat ‘ geen links naar harde mappen toe.
• Sym-links naar mappen ” schenden vaste semantiek en gedrag “, maar ze zijn nog steeds toegestaan. Sommige commandos hebben daarom opties nodig om te bepalen of sym-koppelingen worden gevolgd (bijv. -L in find en cp). Wanneer een programma ‘ .. ‘ volgt, is er nog meer verwarring, vandaar het verschil in uitvoer van pwd en / bin / pwd na het doorlopen van een sym koppeling. Er zijn geen ” Unix-antwoorden “; alleen ontwerpbeslissingen. Deze draait om wat er wordt van ” .. ” zoals ik in mijn antwoord zei. ‘ .. ‘ wordt helaas niet ‘ vermeld in het antwoord dat alle anderen stemt zo schaapachtig voor.
• Trouwens, ik ‘ zeg niet dat ik ‘ ben voor harde links naar dirs. Helemaal niet. Ik wil niet ‘ niet dat mijn dagelijkse baan moeilijker is dan het al is.
• Het ‘ is niet wat POSIX zegt, maar IMO ‘ .. ‘ had nooit een bestandssysteemconcept mogen zijn, maar syntactisch opgelost op de paden, zodat a/.. zou altijd . betekenen. Dit is trouwens hoe URLs werken. Het ‘ is de browser die ‘ s het oplossen van ‘ .. ‘ voordat het zelfs maar de server bereikt. En het werkt geweldig.

Het maken van harde links in mappen zou onomkeerbaar zijn. Stel dat we hebben:

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

Ik koppel het hard aan /dir2.

Dus /dir2 bevat nu ook al deze bestanden en mappen

Wat moet ik doen als ik van gedachten verander? Ik kan “t gewoon rmdir /dir2 (omdat het niet leeg is)

En als ik recursief verwijder in /dir2. .. het zal ook worden verwijderd uit /dir1!

IMHO het is een grotendeels voldoende reden om dit te vermijden!

Bewerken:

Reacties suggereren het verwijderen van de directory door rm erop te doen .Maar rm op een niet-lege map mislukt, en dit gedrag moet blijven bestaan, ongeacht of de map een hardlink heeft of niet. U kunt dus “t rm het gewoon ontkoppelen. Het zou een nieuw argument voor rm vereisen, gewoon om te zeggen” als de directory inode heeft een referentietelling> 1, ontkoppel dan alleen de directory “.

Wat op zijn beurt weer een ander principe van minste verrassing doorbreekt: het betekent dat het verwijderen van een directory-hardlink die ik zojuist heb gemaakt niet hetzelfde is als verwijderen van een normaal bestand hardlink …

Ik zal mijn zin anders formuleren: Zonder verdere ontwikkeling zou het maken van een hardlink onherroepelijk zijn (aangezien geen enkel huidig commando de verwijdering zou kunnen afhandelen zonder onsamenhangend te zijn met het huidige gedrag)

Als we meer ontwikkeling toestaan om de zaak af te handelen, het aantal valkuilen en het risico van gegevensverlies als u “niet genoeg weten hoe het systeem werkt, zoals een dergelijke ontwikkeling impliceert, is IMHO een voldoende reden om hardlinking op mappen te beperken.

Reacties

• Dat zou geen probleem moeten zijn. In uw geval, wanneer we een hardlink naar dir2 maken, moeten we een hardlink maken naar alle inhoud in dir1 en dus als we dir2 hernoemen of verwijderen, wordt alleen een extra link naar de inode verwijderd. En dat zou geen invloed moeten hebben op dir1 en zijn inhoud, aangezien er ten minste één link (dir1) naar de inode is.
• Uw argument is onjuist. Je zou het gewoon ontkoppelen, niet rm -rf. En als het aantal koppelingen 0 bereikt, weet het systeem dat het ook alle inhoud kan verwijderen.
• Dat ‘ is min of meer allemaal rm doet er toch onder (ontkoppelen). Zie: unix.stackexchange.com/questions/151951/… Dit is echt niet ‘ t een probleem, net zo min als met hardlinked bestanden. Door te ontkoppelen wordt alleen de genoemde referentie verwijderd en wordt het aantal links verlaagd. Het feit dat rmdir ‘ won om niet-lege mappen te verwijderen, is niet relevant – het zou niet ‘ doe dat ook niet voor dir1. Hardlinks zijn geen ‘ t kopieën van gegevens, ze zijn hetzelfde daadwerkelijke bestand, dus ” verwijderen ” het dir2-bestand zou de directorylijst voor dir1 wissen. Je zou altijd moeten ontkoppelen.
• Je kunt ‘ niet gewoon ontkoppelen zoals een normaal bestand, omdat rm op een directory don ‘ t ontkoppelen als het ‘ niet leeg is. Zie Bewerken.

Dit is een goede uitleg. Betreffende “Naar welke van de meerdere ouders moet .. wijzen?” een oplossing zou zijn dat een proces zijn volledige wd-pad behoudt, hetzij als inodes, hetzij als een string. inodes zouden robuuster zijn omdat namen kunnen worden gewijzigd. Vroeger was er tenminste een in-core inode voor elk geopend bestand dat werd verhoogd wanneer een bestand werd geopend, verlaagd wanneer het werd gesloten. Toen het nul bereikte, zou het en de opslag waarnaar het wees, worden vrijgegeven. Als het bestand door niemand meer werd geopend, zou het (de in-core-kopie) worden verlaten. Hierdoor zou het pad geldig blijven als een ander proces een directory naar een andere directory zou verplaatsen terwijl de subdirectory zich in het pad van een ander proces bevond. Vergelijkbaar met hoe u een geopend bestand kunt verwijderen, maar het wordt gewoon uit de directory verwijderd, maar nog steeds open voor alle processen die het open hebben.

Hard-linking directories waren vroeger vrij toegestaan in Bell Labs UNIX, tenminste V6 en V7, weet niets van Berkeley of hoger. Geen vlag vereist. Kun je loops maken? Ja, doe dat niet. Het is heel duidelijk wat je doet als je een lus maakt. Nether zou je moeten oefenen met het knopen van knopen om je nek terwijl je wacht op je beurt om uit een vliegtuig te skydiven, als je het andere uiteinde handig aan een haak aan het schot hebt gehangen.

Wat Ik hoopte er vandaag mee te doen, was om lhome naar home te koppelen, zodat ik / home / administ beschikbaar kon hebben, of / home nu wel of niet bedekt was met een automout boven thuis, die automount een symlink heeft met de naam administ naar / lhome / administ. Hierdoor heb ik een beheerdersaccount dat werkt ongeacht de staat van mijn primaire thuisbestandssysteem. Dit IS is een experiment voor linux, maar ik denk dat ik ooit heb geleerd voor het op UCB gebaseerde SunOS dat automounts worden gedaan op het ascii-stringniveau. Het is moeilijk in te zien hoe ze anders gedaan zouden kunnen worden als een laag bovenop een willekeurige FS.

Ik heb dat elders gelezen. en .. staan ook geen bestanden meer in de directory. Ik ben er zeker van dat er goede redenen zijn voor dit alles, en dat veel van wat we leuk vinden (zoals het kunnen mounten van NTFS) mogelijk is vanwege dergelijke dingen, maar een deel van de elegantie van UNIX zat in de implementatie.Het zijn de voordelen zoals algemeenheid en kneedbaarheid die deze elegantie bood, waardoor het zo robuust is en vier decennia lang standhoudt. Als we de elegante implementaties verliezen, zal het uiteindelijk als Windows worden (ik hoop dat ik het mis heb!). Iemand zou dan een nieuw besturingssysteem maken dat is gebaseerd op elegante principes. Iets om over na te denken. Misschien heb ik het mis, ik ben (uiteraard) niet bekend met de huidige implementatie. Het is echter verbazingwekkend hoe toepasselijk de 30 jaar oude kennis is op Linux … meestal!

Reacties

• Ik denk, hoewel ik het mis kan hebben, dat . en .. geen hardlinks zijn in het bestandssysteem, voor moderne bestandssystemen. Het stuurprogramma van het bestandssysteem vervalst ze echter. Het zijn deze bestandssystemen die het blokkeren van mappen stoppen. Voor oude bestandssystemen was het mogelijk (maar gevaarlijk). Om te doen wat je probeert, kijk je naar mount --bind, zie ook mount --make… en misschien containers.

Van wat ik begrijp, is de belangrijkste reden dat het handig is om directorynamen te kunnen wijzigen zonder actieve programmas die hun werkdirectory om naar andere bestanden te verwijzen. Stel dat u Wine gebruikt om ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe uit te voeren, en u wilt in plaats daarvan het hele voorvoegsel verplaatsen naar ~/.wine. Als Firefox om een of andere vreemde reden toegang had tot drive_c/windows door te verwijzen naar ../../windows, wordt de naam van ~/.newwineprefix verbroken implementaties van .. die de bovenliggende map bijhouden als een tekstreeks in plaats van een inode.

Het opslaan van de inode van een enkele bovenliggende map moet eenvoudiger zijn dan proberen om elk pad bij te houden als zowel een tekstreeks als een reeks inodes.

Een andere reden is dat wangedrag ng-toepassingen kunnen mogelijk loops maken. Gedragende applicaties zouden in staat moeten zijn om te controleren of de inode van de directory die wordt verplaatst dezelfde is als de inode van een van de geneste directories waar deze naartoe wordt verplaatst, net zoals je een directory niet naar zichzelf kunt verplaatsen, maar dit wordt mogelijk niet afgedwongen op het niveau van het bestandssysteem.

Nog een andere reden zou kunnen zijn dat als je mappen zou kunnen hard linken, je zou willen voorkomen dat je een map hard linkt die je niet zou kunnen wijzigen. find heeft veiligheidsoverwegingen omdat het wordt gebruikt om bestanden te wissen die door andere gebruikers zijn gemaakt uit tijdelijke mappen, wat problemen kan veroorzaken als een gebruiker naar een echte map wisselt voor een symlink terwijl find roept een ander commando aan. Als je in staat zou zijn om belangrijke mappen hard te koppelen, zou een beheerder gedwongen worden om extra tests toe te voegen aan find om te voorkomen dat ze beïnvloed worden. (Ok, je hebt al kan dit “niet doen voor bestanden, dus deze reden is ongeldig.)

Nog een andere reden is dat het opslaan van de inode van de bovenliggende directory extra redundantie kan bieden in het geval van beschadiging of beschadiging van het bestandssysteem. wilde .. om alle bovenliggende mappen weer te geven die hard linken naar deze, zodat een andere, willekeurige ouder gemakkelijk kan worden gevonden als de huidige is ontkoppeld, niet alleen schendt u het idee dat moeilijk links gelijk zijn, moet u de manier wijzigen waarop het bestandssysteem inodes opslaat en gebruikt. Programmas laten behandelen paden als een reeks (uniq ue naar elke hardlink) van directory-inodes zou dit vermijden, maar u zou de redundantie niet krijgen in geval van beschadiging van het bestandssysteem.