Hvorfor er hårde links til mapper ikke tilladt i UNIX / Linux?

Dette er bare en dårlig idé, som der er ingen måde at fortælle forskellen på et hårdt link og et originalt navn.

Tilladelse af hårde links til kataloger ville bryde den dirigerede acykliske grafstruktur i filsystemet og muligvis skabe katalogsløjfer og dinglende katalogundertrær, hvilket gør fsck og enhver anden filtrævandrer fejl udsat.

Først skal vi tale om inoder for at forstå dette. Dataene i filsystemet holdes i blokke på disken, og disse blokke samles sammen af en inode. Du kan tænke på inoden som filen. Inoder mangler dog filnavne. Det er her links kommer ind.

Et link er bare en markør til en inode. En mappe er en inode, der indeholder links. Hvert filnavn i et bibliotek er kun et link til en inode. Åbning af en fil i Unix opretter også et link, men det er en anden type link (det er ikke et navngivet link).

Et hårdt link er bare en ekstra katalogindgang, der peger på den inode. Når du ls -l, er antallet efter tilladelserne det navngivne linkantal. De fleste almindelige filer har et link. Oprettelse af et nyt hardt link til en fil vil få begge filnavne til at pege på den samme inode. Bemærk:

% 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 kan du tydeligt se, at der ikke er noget, der hedder et hårdt link. Et hårdt link er det samme som et almindeligt navn. I eksemplet ovenfor, test eller test2, hvilken originalfil er der, og hvilken er det hårde link? I slutningen kan du ikke rigtig fortælle (selv ved tidsstempler), fordi begge navne peger på det samme indhold, den samme 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 flag til ls viser dig inodenumre i begyndelsen af linjen. Bemærk hvordan test og test2 har det samme inodenummer, men test3 har en anden.

Hvis du nu fik lov til at gør dette for mapper, to forskellige kataloger i forskellige punkter i filsystemet kunne pege på det samme. Faktisk kunne en undermappe pege tilbage til sin bedsteforælder og skabe en loop.

Hvorfor er denne loop en bekymring ? Fordi når du kører, er der ingen måde at opdage, at du løkker (uden at holde styr på inode numre, når du krydser). Forestil dig, at du skriver kommandoen du, som skal tilbagekald gennem subdirs for at finde ud af om diskbrug. Hvordan ville du vide, hvem n det ramte en løkke? Det er fejlbehæftet og en masse bogføring, at du skulle gøre, bare for at udføre denne enkle opgave.

Symlinks er et helt andet dyr, i at de er en særlig type “fil”, som mange filfilsystem-APIer har tendens til automatisk at følge. Bemærk, et symlink kan pege på en ikke-eksisterende destination, fordi de peger ved navn og ikke direkte på en inode. Dette koncept giver ikke mening med hårde links, fordi den blotte eksistens af et “hårdt link” betyder, at filen findes.

Så hvorfor kan du håndtere symlinks nemt og ikke hårde links? Vi kunne se ovenfor, at hårde links ikke kan skelnes fra normale biblioteksposter. Symlinks er dog specielle, detekterbare og kan springes over! symlink er et symlink, og springer det helt 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 . 

Kommentarer

• Allowing hard links to directories would break the directed acyclic graph structure of the filesystem.Kan du venligst forklare mere om problemet med cyklusser ved hjælp af hårde links? Hvorfor er det ok med symlinks
• De ser ud til at have tilladt det på Macer ved at føje cyklusregistrering til link () systemopkaldet og nægte at tillade dig at oprette et harddiskforbindelse, hvis det ville skabe en cyklus . Synes at være en rimelig løsning.
• @psusi mkdir -p a / b; nocheckln c a; mv c a / b; – nocheckln der er en teoretisk ln, der ikke kontrollerer for katalogargs, og bare overgår til link, og fordi der ikke laves nogen cyklus, er vi alle gode til at skabe ‘ c ‘. så flytter vi ‘ c ‘ til ‘ a / b ‘, og der oprettes en cyklus ud fra a / b / c – > a / – check-in link () er ikke god nok
• Cykler er meget dårlige. Windows har dette problem med ” vejkryds “, som er hardlink-mapper. Hvis du ved et uheld anvender tilladelser til hele din profil, afdækker den en række kryds, der skaber en uendelig cyklus. Gendannelse gennem mapperne gentager sig, indtil begrænsningerne for længden af stien stopper det.
• @WhiteWinterWolf, ifølge dette link tilføjede de specifikt support til det til tidsmaskine, men kun root har tilladelse til at gøre det: superbruger.com/questions/360926/…

Du kan bruge bind mount til at simulere hardlink-kataloger

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

Med undtagelse af monteringspunkter har hver bibliotek en eneste forælder: ...

En måde at gør pwd er at kontrollere enheden: inode for “.” og “..”. Hvis de er de samme, har du nået roden til filsystemet. Ellers skal du finde navnet på den aktuelle mappe i den overordnede, skubbe det på en stak og begynde at sammenligne “../.” med “../ ..”, derefter “../../.” med “../../ ..” osv. Når du først har ramt roden, skal du begynde at poppe og udskrive navnene fra stakken. Denne algoritme er afhængig af det faktum, at hver mappe har en og kun en forælder. p>

Hvis hårde links til mapper blev tilladt, hvilken af de flere forældre skal .. pege på? Det er en overbevisende grund til, at hardlinks til mapper ikke er tilladt.

Symlinks til mapper forårsager ikke dette problem. Hvis et program ønsker det, kan det udføre en lstat() på hver del af stienavnet og registrere, når der opstår et symlink. pwd -algoritmen returnerer det sande absolutte stienavn for en målkatalog. Det faktum, at der er et stykke tekst et eller andet sted (symlinket), der peger på målkataloget, er stort set irrelevant. Eksistensen af et sådant symlink skaber ikke en sløjfe i grafen.

Kommentarer

• Ikke så sikker på dette. Hvis vi tænker på .. som en slags virtuel hardlink til forældrene, er der ingen teknisk grund til, at målet for linket kun kan have et andet link til det. pwd skulle bare bruge en anden algoritme til at løse stien.

Intet af følgende er den egentlige årsag til ikke at tillade hårde links til mapper; hvert problem er ret let at løse:

• cyklusser i træstrukturen forårsager vanskelig gennemgang
• flere forældre, så hvilken er den “rigtige”?
• filsystem affaldssamling

reel grund (som antydet af @ Thorbjørn Ravn Andersen) kommer, når du sletter en mappe, der har flere forældre, fra den mappe, der er peget på af ..:

Hvad skal .. nu pege på?

Hvis biblioteket slettes fra dets overordnede, men dets antal links er stadig større end 0 så skal der være noget, der stadig peger på det. Du kan ikke lade .. pege på intet; mange programmer er afhængige af .., så systemet bliver nødt til at krydse hele filsystemet indtil det finder den første ting, der peger på den slettede mappe, bare for at opdatere ... Enten det, eller filsystemet skal have en liste over alle mapper, der peger på et hardt linket bibliotek.

Uanset hvad ville dette være en overhead og en ekstra komplikation til filsystemets metadata og / eller kode, så designerne besluttede ikke at tillade det.

Kommentarer

• At ‘ også er let at løse: Hold en liste over forældre til et underordnet bibliotek, som du opdaterer, når du tilføjer eller fjerner et link til barnet. Når du sletter den kanoniske forælder (mål for barnet ‘ s

  ), opdater .. for at pege på en af de andre forældre på listen.

• Jeg er enig. Ikke raketvidenskab at løse. Men ikke desto mindre en performance overhead, og det ville tage lidt ekstra plads i filsystemets metadata og tilføje komplikationer. Og så gik designerne efter den enkle, hurtige tilgang – don ‘ t tillad links til hårde mapper.
• Sym-links til dirs ” overtræder afviklet semantik og adfærd “, men alligevel er de stadig tilladt. Nogle kommandoer har derfor brug for muligheder for at kontrollere, om sym-links følges (f.eks. -L i find og cp). Når et program følger ‘ .. ‘ er der yderligere forvirring, derfor er forskellen i output fra pwd og / bin / pwd efter at have krydset en sym link. Der er ingen ” Unix-svar “; bare designbeslutninger. Denne drejer sig om, hvad der bliver af ” .. ” som jeg sagde i mit svar. Desværre er ‘ .. ‘ ikke ‘ t nævnt i svaret, at alle andre stemmer så fårligt.
• BTW, jeg ‘ siger ikke jeg ‘ m til fordel for hårde links til dirs. Slet ikke. Jeg ønsker ikke ‘ at mit daglige job skal være hårdere, end det allerede er.
• Det ‘ er ikke hvad POSIX siger, men IMO ‘ .. ‘ skulle aldrig have været et filsystemkoncept, snarere løst syntaktisk på stierne, så a/.. vil altid betyde .. Sådan fungerer URL-adresser btw. Det ‘ er browseren, som ‘ s løser ‘ .. ‘, før den endda rammer serveren. Og det fungerer godt.

Oprettelse af hardlink i mapper ville være uoprettelig. Antag, at vi har:

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

Jeg hardlinker det til /dir2.

Så /dir2 indeholder nu også alle disse filer og mapper

Hvad hvis jeg skifter mening? Jeg kan “t bare rmdir /dir2 (fordi det ikke er tomt)

Og hvis jeg rekursivt sletter i /dir2. .. det slettes også fra /dir1!

IMHO det er en stort set tilstrækkelig grund til at undgå dette!

Rediger:

Kommentarer foreslår at fjerne biblioteket ved at gøre rm på det .Men rm i en ikke-tom mappe mislykkes, og denne adfærd skal forblive, uanset om biblioteket er hardlinket eller ej. Så du kan “t bare rm for at fjerne linket. Det ville kræve et nyt argument til rm, bare for at sige” hvis biblioteket inode har en referencetælling> 1, fjern derefter kun linket til biblioteket “.

Hvilket igen bryder et andet princip med mindst overraskelse: det betyder, at fjernelse af en kataloghardlink, jeg lige har oprettet, ikke er det samme som fjernelse af en normal fil-hardlink …

Jeg vil omformulere min sætning: Uden yderligere udvikling ville oprettelse af hardlink være uoprettelig (da ingen aktuel kommando kunne håndtere fjernelsen uden at være usammenhængende med den aktuelle adfærd)

Hvis vi tillader mere udvikling at håndtere sagen, antallet af faldgruber og risikoen for datatab hvis du “er ikke nok klar over, hvordan systemet fungerer, sådan en udvikling antyder, er IMHO en tilstrækkelig grund til at begrænse hardlinking til mapper.

Kommentarer

• Det burde ikke være et problem. Når du opretter hardlink til dir2, skal vi oprette hardlink til alt indholdet i dir1, og så hvis vi omdøber eller sletter dir2, bliver kun et ekstra link til inoden slettet. Og det bør ikke påvirke dir1 og dets indhold, da der mindst er et link (dir1) til inoden.
• Dit argument er forkert. Du vil bare fjerne linket til det, ikke gøre rm -rf. Og hvis linkantalet når 0, ville systemet vide, at det også kan slette alt indholdet.
• At ‘ er mere eller mindre alle rm gør det alligevel under (fjern linket). Se: unix.stackexchange.com/questions/151951/… Dette er virkelig ikke ‘ ikke et problem mere end det er med hardlinkede filer. Fjernelse af link fjerner bare den navngivne reference og reducerer antallet af link. Det faktum, at rmdir vandt ‘ ikke sletter ikke-tomme mapper, er irrelevant – det ville ikke være ‘ t gør det for dir1 enten. Hardlinks er ikke ‘ t kopier af data, de er den samme faktiske fil, og derfor ” sletter ” dir2-filen vil slette katalogoversigten for dir1. Du skal altid fjerne linket.
• Du kan ‘ ikke bare fjerne linket som en normal fil, fordi rm i et bibliotek don ‘ t fjern linket, hvis det ‘ ikke er tomt. Se Rediger.

Dette er en god forklaring. Med hensyn til “Hvilken af de flere forældre skal .. pege på?” en løsning ville være, at en proces opretholder sin fulde wd-sti, enten som inoder eller som en streng. inoder ville være mere robuste, da navne kan ændres. I det mindste i gamle dage var der en inode-inode for hver åben fil, der blev steget, hver gang en fil blev åbnet, dekrementeret, når den blev lukket. Når det nåede nul, frigøres det og det lager, det pegede på. Når filen ikke længere var åben af nogen, ville den (kernekopien) blive opgivet. Dette ville opretholde stien som gyldig, hvis en anden proces flyttede en mappe til en anden mappe, mens underkatalogen var i stien til en anden proces. På samme måde som hvordan du kan slette en åben fil, men den fjernes simpelthen fra biblioteket, men stadig åben for alle processer, der har den åben.

Hårdkoblingsmapper var tidligere frit tilladt i Bell Labs UNIX, i det mindste V6 og V7, ved ikke Berkeley eller senere. Intet flag krævet. Kunne du lave sløjfer? Ja, gør det ikke. Det er meget klart, hvad du laver, hvis du laver en løkke. Nether bør du øve dig på at binde knude omkring din hals, mens du venter på din tur til at hoppe ud af et fly, hvis du har den anden ende bekvemt hængt fra en krog på hovedhovedet.

Hvad Jeg håbede at gøre med det i dag var at knytte hjemmet hårdt til hjemmet, så jeg kunne have / home / administ til rådighed, uanset om / home var dækket af en automout over hjemmet, den automount havde et symlink med navnet administ til / lhome / administ. Dette giver mig mulighed for at have en administrativ konto, der fungerer uanset tilstanden til mit primære hjemmefilsystem. Dette ER et eksperiment for linux, men jeg tror, jeg lærte på én gang for UCB-baserede SunOS, at automatiske udførelser sker på ascii-strengniveau. Det er svært at se, hvordan de ellers kunne gøres som et lag oven på en vilkårlig FS.

Jeg læste det andetsteds. og .. er heller ikke filer mere i biblioteket. Jeg er sikker på, at der er gode grunde til alt dette, og at meget af det, vi nyder (såsom at være i stand til at montere NTFS) er muligt på grund af sådanne ting, men noget af UNIXs elegance var i implementeringen.Det er fordelene som generalitet og formbarhed, at denne elegance forudsat, at det har gjort det muligt at være så robust og udholde i fire årtier. Når vi mister de elegante implementeringer, bliver det til sidst som Windows (jeg håber, jeg tager fejl!). Nogen ville derefter oprette et nyt operativsystem, der er baseret på elegante principper. Noget at tænke over. Måske tager jeg fejl, jeg er (åbenbart) ikke fortrolig med den nuværende implementering. Det er forbløffende, hvor anvendelig 30 år gammel forståelse er for Linux … det meste af tiden!

Kommentarer

• Jeg tror, selvom jeg kan have forkert, at . og .. ikke er hardlinks i filsystemet til moderne filsystemer. Imidlertid fejler filsystemdriveren dem. Det er disse filsystemer, der stopper hard-link-kataloger. For gamle filsystemer var det muligt (men farligt). For at gøre det, du prøver, skal du se på mount --bind, se også mount --make… og måske containere.

Fra det, jeg samler, er hovedårsagen, at det er nyttigt at kunne ændre katalognavne uden at ødelægge kørende programmer, der bruger deres arbejdskatalog for at henvise til andre filer. Antag at du brugte Wine til at køre ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe, og du ville i stedet flytte hele præfikset til ~/.wine. Hvis Firefox af en eller anden mærkelig grund havde adgang til drive_c/windows ved at henvise til ../../windows, omdøbes ~/.newwineprefix implementeringer af .., der holder styr på den overordnede mappe som en tekststreng i stedet for en inode.

At gemme inoden i en enkelt overordnet mappe skal være enklere end at prøve for at holde styr på hver sti som både en tekststreng og en række inoder.

En anden grund er, at de opfører sig forkert ng-applikationer kan muligvis oprette sløjfer. Opførsel af applikationer skal være i stand til at kontrollere, om inoden i det bibliotek, der flyttes, er den samme som inoden i et af de indlejrede mapper, det flyttes til, ligesom du ikke kan flytte en mappe til sig selv, men dette muligvis ikke håndhæves på filsystemniveau.

Endnu en anden årsag kan være, at hvis du kunne hardlink-mapper, ville du forhindre hardlinking af en mappe, som du ikke kunne ændre. find har sikkerhedsmæssige overvejelser, fordi det bruges til at rydde filer oprettet af andre brugere fra midlertidige mapper, hvilket kan forårsage problemer, hvis en bruger skifter et rigtigt bibliotek til et symlink, mens find påkalder en anden kommando. At kunne hardlinke vigtige mapper vil tvinge en administrator til at føje ekstra tests til find for at undgå at påvirke dem. (Ok, du allerede kan ikke “gøre dette for filer, så denne årsag er ugyldig.)

Endnu en årsag er, at lagring af den overordnede biblioteks inode kan give ekstra redundans i tilfælde af korruption eller beskadigelse af filsystemet. Hvis du ville have .. til at liste alle overordnede mapper, der er hardlink til denne, så en anden, vilkårlig forælder kunne let findes, hvis den nuværende er fjernet, ikke kun bryder du ideen om, at links er lige, skal du ændre, hvordan filsystemet gemmer og bruger inoder. At have programmer behandler stier som en serie (uniq ue til hvert hardlink) af katalogindkoder ville undgå dette, men du ville ikke få redundansen i tilfælde af beskadigelse af filsystemet.