Hvorfor er ikke harde lenker til kataloger tillatt i UNIX / Linux?

Dette er bare en dårlig idé, som der er ingen måte å se forskjellen mellom en hard lenke og et originalt navn.

Å tillate harde lenker til kataloger vil ødelegge den dirigerte asykliske grafstrukturen i filsystemet, muligens skape katalogsløyfer og dinglende katalogundertrær, noe som gjør fsck og andre filtreetokere feil utsatt.

Først, for å forstå dette, la oss snakke om inoder. Dataene i filsystemet holdes inne blokker på disken, og disse blokkene samles sammen av en inode. Du kan tenke på inoden som filen. Inoder mangler imidlertid filnavn. Det er der koblinger kommer inn.

En lenke er bare en peker til en inode. En katalog er en inode som inneholder lenker. Hvert filnavn i en katalog er bare en lenke til en inode. Å åpne en fil i Unix oppretter også en kobling, men den er en annen type kobling (den er ikke en navngitt lenke).

En hard lenke er bare en ekstra katalogoppføring som peker til den inoden. Når du ls -l, er tallet etter tillatelsene det navngitte antall lenker. De fleste vanlige filer vil ha en lenke. Hvis du oppretter en ny hard lenke til en fil, vil begge filnavnene peke på den samme inoden. Merk:

% 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 

Nå kan du tydelig se at det ikke er noe som heter en hard link. En hard lenke er det samme som et vanlig navn. I eksemplet ovenfor, test eller test2, hvilken er den opprinnelige filen og hvilken er den harde lenken? På slutten kan du ikke virkelig fortelle (selv med tidsstempler) fordi begge navnene peker på samme innhold, 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 flagg til ls viser inodenumre i begynnelsen av linjen. Merk hvordan test og test2 har samme inode nummer, men test3 har et annet nummer.

Nå, hvis du fikk lov til gjør dette for kataloger, to forskjellige kataloger i forskjellige punkter i filsystemet kan peke på det samme. Faktisk kan en undermappe peke tilbake til besteforelderen og skape en løkke.

Hvorfor er denne sløyfen en bekymring ? For når du krysser, er det ingen måte å oppdage at du sløyfer (uten å holde oversikt over inode-tall mens du krysser). Tenk deg at du skriver kommandoen du resursere gjennom subdirs for å finne ut om diskbruk. Hvordan ville du vite hvem n det traff en løkke? Det er feil utsatt og mye bokføring som du må gjøre, bare for å utføre denne enkle oppgaven.

Symlinks er et helt annet dyr, i at de er en spesiell type «fil» som mange filfilsystem-API-er pleier å automatisk følge. Merk at en symlink kan peke til et ikke-eksisterende mål, fordi de peker etter navn og ikke direkte til en inode. Det konseptet gir ikke mening med harde lenker, fordi bare den eksistensen av en «hard link» betyr at filen eksisterer.

Så hvorfor kan du håndtere Vi kan se ovenfor at harde lenker ikke kan skilles fra normale katalogoppføringer. Symlinker er imidlertid spesielle, detekterbare og kan hoppes over! du merker at symlink er en symlink, og hopper over den helt!

% 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 forklare mer om problemet med sykluser ved hjelp av harde lenker? Hvorfor er det greit med symlinker
• De ser ut til å ha tillatt det på Mac-maskiner ved å legge til syklusoppdagelse i systemanropet for lenken (), og nekter å tillate deg å opprette en hard lenke til katalogen hvis det ville skape en syklus . Ser ut til å være en rimelig løsning.
• @psusi mkdir -p a / b; nocheckln c a; mv c a / b; – Nocheckln det er en teoretisk ln som ikke ser etter katalog args, og bare går til lenke, og fordi ingen syklus er laget, er vi alle gode til å lage ‘ c ‘. så flytter vi ‘ c ‘ til ‘ a / b ‘, og en syklus blir opprettet fra a / b / c – > a / – det er ikke bra å sjekke inn lenke ()
• Sykler er veldig dårlige. Windows har dette problemet med » veikryss » som er hardlink-kataloger. Hvis du ved et uhell bruker tillatelser til hele profilen din, avdekker den en serie kryss som skaper en uendelig syklus. Gjentakelse gjennom katalogene går tilbake til begrensningene for banelengden stopper det.
• @WhiteWinterWolf, ifølge denne lenken la de spesifikt til støtte for det for tidsmaskiner, men bare root har lov til å gjøre det: «29bc5bebe9»>

Du kan bruke bindemontering til å simulere kataloger med hardkobling

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

Med unntak av monteringspunkter, har hver katalog en eneste foreldre: ...

En måte å gjør pwd er å sjekke enheten: inode for «.» og «..». Hvis de er de samme, har du nådd roten til filsystemet. Ellers finner du navnet på den gjeldende katalogen i foreldrene, skyver det på en bunke og begynner å sammenligne «../.» med «../ ..», deretter «../../.» med «../../ ..» osv. Når du har kommet til roten, begynn å poppe og skrive ut navnene fra bunken. Denne algoritmen er avhengig av at hver katalog har en og bare en forelder.

Hvis harde lenker til kataloger var tillatt, hvilken av foreldrene skal .. peke på? Det er en overbevisende årsak til at hardlenker til kataloger ikke er tillatt.

Symlinker til kataloger forårsaker ikke det problemet. Hvis et program vil, kan det gjøre en lstat() på hver del av banenavnet og oppdage når en symlink oppstår. pwd -algoritmen vil returnere det sanne absolutte stienavnet for en målkatalog. Det faktum at det er et stykke tekst et sted (symlinket) som peker mot målkatalogen, er ganske irrelevant. Eksistensen av en slik symlink skaper ikke en løkke i grafen.

Kommentarer

• Ikke så sikker på dette. Hvis vi tenker på .. som en slags virtuell hardlink til foreldrene, er det ingen teknisk grunn til at målet for lenken bare kan ha en annen lenke til den. pwd må bare bruke en annen algoritme for å løse banen.

Ingen av følgende er den virkelige årsaken til at du ikke tillater harde lenker til kataloger; hvert problem er ganske enkelt å løse:

• sykluser i trestrukturen forårsaker vanskelig gjennomgang
• flere foreldre, så hvem er den «virkelige»?
• søppelsamling av filsystem

reell grunn (som antydet av @ Thorbjørn Ravn Andersen) kommer når du sletter en katalog som har flere foreldre, fra katalogen pekt til av ..:

Hva skal .. nå peke på?

Hvis katalogen slettes fra den overordnede, men dens antall lenker er fortsatt større enn 0 så må det være noe, et sted som fremdeles peker på det. Du kan ikke la .. peke på ingenting; mange programmer er avhengige av .., så systemet må krysse hele filsystemet til det finner det første som peker på den slettede katalogen, bare for å oppdatere ... Enten det, eller filsystemet må ha en liste over alle kataloger som peker på en hardkoblet katalog.

Uansett vil dette være en ytelse overhead og en ekstra komplikasjon for filsystemets metadata og / eller kode, så designerne bestemte seg for ikke å tillate det.

Kommentarer

• At ‘ også er lett å løse: føre en liste over foreldre til en barnekatalog, som du oppdaterer når du legger til eller fjerner en lenke til barnet. Når du sletter den kanoniske forelderen (målet for barnet ‘ s

  ), oppdater .. for å peke på en av de andre foreldrene i listen.

• Jeg er enig. Ikke rakettvitenskap å løse. Men likevel en ytelse overhead, og det vil ta litt ekstra plass i filsystemets metadata og legge til komplikasjoner. Og så gikk designerne for den enkle, raske tilnærmingen – ikke ‘ t tillater lenker til harde kataloger.
• Sym-lenker til dirs » bryter med avgjort semantikk og atferd «, men de er fortsatt tillatt. Noen kommandoer trenger derfor alternativer for å kontrollere om sym-lenker følges (f.eks. -L i find og cp). Når et program følger ‘ .. ‘ er det ytterligere forvirring, derav forskjellen i utdata fra pwd og / bin / pwd etter å ha krysset en sym-lenke. Det er ingen » Unix-svar «; bare designbeslutninger. Denne dreier seg om hva som blir av » .. » som jeg uttalte i svaret mitt. Dessverre er ‘ .. ‘ ikke ‘ t til og med nevnt i svaret at alle andre stemmer så fårete.
• BTW, jeg ‘ Jeg sier ikke at jeg ‘ m til fordel for harde lenker til dirs. Ikke i det hele tatt. Jeg vil ikke ‘ at dagjobben min skal være vanskeligere enn den allerede er.
• Det ‘ er ikke hva POSIX sier, men IMO ‘ .. ‘ burde aldri vært et filsystemkonsept, heller løst syntaktisk på stiene, slik at a/.. vil alltid bety .. Slik fungerer nettadresser btw. Det ‘ er nettleseren som ‘ løser ‘ .. ‘ før den til og med treffer serveren. Og det fungerer bra.

Opprettelse av hardlink i kataloger vil være ugjenkallelig. Anta at vi har:

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

Jeg knytter det hardt til /dir2.

Så /dir2 inneholder nå også alle disse filene og katalogene

Hva om jeg ombestemmer meg? Jeg kan «t bare rmdir /dir2 (fordi den ikke er tom)

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

IMHO det er i stor grad tilstrekkelig grunn til å unngå dette!

Rediger:

Kommentarer antyder at du fjerner katalogen ved å gjøre rm på den .Men rm i en ikke-tom katalog mislykkes, og denne oppførselen må forbli, uansett om katalogen er hardkoblet eller ikke. Så du kan «t bare rm for å fjerne tilknytningen. Det vil kreve et nytt argument for å rm, bare for å si» hvis katalogen inode har et referansetall> 1, så fjerner du bare koblingen til katalogen «.

Som i sin tur bryter et annet prinsipp av minst overraskelse: det betyr at fjerning av en kataloghardlink jeg nettopp opprettet ikke er det samme som fjerning av en vanlig filhardlink …

Jeg vil omformulere setningen min: Uten videre utvikling vil hardlink-opprettelse være ugjenkallelig (da ingen nåværende kommandoer kan håndtere fjerningen uten å være usammenhengende med gjeldende oppførsel)

Hvis vi lar mer utvikling håndtere saken, antall fallgruver og risikoen for tap av data hvis du «er ikke nok klar over hvordan systemet fungerer, slik en utvikling tilsier, er IMHO en tilstrekkelig grunn til å begrense hardlinking i kataloger.

Kommentarer

• Det burde ikke være et problem. Når du oppretter hardlink til dir2, må vi lage hardlink til alt innholdet i dir1, og hvis vi omdøper eller sletter dir2, blir bare en ekstra lenke til inoden slettet. Og det skal ikke påvirke dir1 og innholdet, da det er minst en lenke (dir1) til inoden.
• Argumentet ditt er feil. Du vil bare fjerne tilknytningen, ikke gjøre rm -rf. Og hvis antall lenker når 0, vil systemet vite at det også kan slette alt innholdet.
• At ‘ er mer eller mindre alt rm gjør det uansett (fjern koblingen). Se: unix.stackexchange.com/questions/151951/… Dette er egentlig ikke ‘ t et problem, mer enn det er med hardkoblede filer. Hvis du fjerner tilknytningen, fjernes bare den navngitte referansen og reduserer antall lenker. Det at rmdir vant ‘ for å slette ikke-tomme kataloger er irrelevant – det ville ikke ‘ t gjør det for dir1 heller. Hardlinker er ikke ‘ t kopier av data, de er den samme faktiske filen, derav faktisk » sletting » dir2-filen vil slette katalogoppføringen for dir1. Du må alltid koble fra.
• Du kan ‘ t bare fjerne tilknytningen som en vanlig fil, fordi rm i en katalog ikke ‘ t fjern lenken hvis den ‘ ikke er tom. Se Rediger.

Dette er en god forklaring. Angående «Hvilken av de flere foreldrene skal .. peke på?» en løsning ville være at en prosess opprettholder sin fulle bane, enten som inoder eller som en streng. inoder ville være mer robuste siden navn kan endres. I det minste i gamle dager var det en inode-inode for hver åpen fil som ble inkrementert hver gang en fil ble åpnet, dekrementert når den ble lukket. Når den nådde null, ble lagringsplassen den pekte på frigjort. Når filen ikke lenger var åpen av noen, ville den (The in-core copy) bli forlatt. Dette vil opprettholde banen som gyldig hvis en annen prosess flyttet en katalog til en annen katalog mens underkatalogen var i banen til en annen prosess. På samme måte som hvordan du kan slette en åpen fil, men den fjernes ganske enkelt fra katalogen, men fortsatt åpen for alle prosesser som har den åpen.

Hardlinkende kataloger var tidligere fritt tillatt i Bell Labs UNIX, i det minste V6 og V7, vet ikke om Berkeley eller senere. Ingen flagg kreves. Kan du lage løkker? Ja, ikke gjør det. Det er veldig klart hva du gjør hvis du lager en løkke. Nedenfor bør du øve på å knyte deg rundt halsen mens du venter på at det blir din tur til fallskjermhopp ut av et fly hvis du har den andre enden praktisk hengt fra en krok på bulk-hodet.

Hva Jeg håpet å gjøre med det i dag, var å koble hjemmet hardt, slik at jeg kunne ha / home / administ tilgjengelig om / home var dekket med en automout over hjemmet, den automount som hadde en symlink kalt administ til / lhome / administ. Dette gjør at jeg kan ha en administrativ konto som fungerer uavhengig av tilstanden til mitt primære hjemmefilsystem. Dette ER et eksperiment for linux, men jeg tror jeg lærte på en gang for UCB-baserte SunOS at automounts gjøres på ascii-strengnivå. Det er vanskelig å se hvordan de kan gjøres ellers som et lag på toppen av noen vilkårlig FS.

Jeg leste det andre steder. og .. er heller ikke filer lenger i katalogen. Jeg er sikker på at det er gode grunner for alt dette, og at mye av det vi liker (som å kunne montere NTFS) er mulig på grunn av slike ting, men noe av elegansen til UNIX var i implementeringen.Det er fordelene som generalitet og smidighet som denne elegansen ga som har gjort det mulig å være så robust og å holde ut i fire tiår. Når vi mister de elegante implementeringene, vil det til slutt bli som Windows (jeg håper jeg tar feil!). Noen ville da lage et nytt operativsystem som er basert på elegante prinsipper. Noe å tenke på. Kanskje jeg tar feil, jeg er ikke (åpenbart) kjent med den nåværende implementeringen. Det er utrolig skjønt hvor anvendelig 30 år gammel forståelse er for Linux … mesteparten av tiden!

Kommentarer

• Jeg tror, selv om jeg kan ta feil, at . og .. ikke er hardkoblinger i filsystemet, for moderne filsystemer. Imidlertid falsker filsystemdriveren dem. Det er disse filsystemene som stopper kataloger med hard kobling. For gamle filsystemer var det mulig (men farlig). For å gjøre det du prøver, se på mount --bind, se også mount --make… og kanskje containere.

Fra det jeg samler, er hovedårsaken at det er nyttig å kunne endre katalognavn uten å ødelegge kjørende programmer som bruker deres arbeidskatalog for å referere til andre filer. Anta at du brukte Wine til å kjøre ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe, og at du ønsket å flytte hele prefikset til ~/.wine i stedet. Hvis Firefox av en eller annen merkelig grunn fikk tilgang til drive_c/windows ved å henvise til ../../windows, vil omdøping av ~/.newwineprefix bryte implementeringer av .. som holder oversikt over foreldrekatalogen som en tekststreng i stedet for en inode.

Lagring av inoden til en enslig foreldrekatalog må være enklere enn å prøve å holde oversikt over alle baner som både en tekststreng og en serie inoder.

En annen grunn er at de oppfører seg dårlig ng-applikasjoner kan kanskje lage sløyfer. Oppførsel av applikasjoner skal kunne sjekke om inoden til katalogen som flyttes er den samme som inoden til noen av nestede kataloger den flyttes til, akkurat som du ikke kan flytte en katalog inn i seg selv, men dette kanskje ikke håndheves på filsystemnivå.

En annen grunn kan være at hvis du kunne hardlink-kataloger, vil du forhindre hardlinking av en katalog du ikke kunne endre. find har sikkerhetshensyn fordi den brukes til å fjerne filer som er opprettet av andre brukere fra midlertidige kataloger, noe som kan forårsake problemer hvis en bruker bytter en ekte katalog for en symlink mens find påkaller en annen kommando. Å kunne hardlinke viktige kataloger vil tvinge en administrator til å legge til ekstra tester i find for å unngå å påvirke dem. (Ok, du allerede kan ikke gjøre dette for filer, så denne årsaken er ugyldig.)

Nok en annen grunn er at lagring av foreldrekatalogens inode kan gi ekstra redundans i tilfelle korrupsjon eller skader på filsystemet. Hvis du ville at .. skulle liste opp alle overordnede kataloger som hardlink til denne, slik at en annen, vilkårlig forelder lett kunne bli funnet hvis den nåværende er linket, ikke bare bryter du ideen om at koblinger er like, må du endre hvordan filsystemet lagrer og bruker inoder. Å ha programmer behandler baner som en serie (uniq ue til hver hardlink) av kataloginoder ville unngå dette, men du vil ikke få overflødighet i tilfelle skader på filsystemet.