Varför är hårda länkar till kataloger inte tillåtna i UNIX / Linux?

Detta är bara en dålig idé, som där är inget sätt att se skillnaden mellan en hård länk och ett originalt namn.

Att låta hårda länkar till kataloger skulle bryta den riktade acykliska grafstrukturen för filsystemet, eventuellt skapa katalogslingor och dinglande katalogunderträd, vilket skulle gör fsck och andra filtree walkers felbenägna.

Först, för att förstå detta, låt oss tala om inoder. Data i filsystemet hålls i block på disken, och dessa block samlas ihop av en inod. Du kan tänka på inoden som filen. Inoder saknar dock filnamn. Det är där länkar kommer in.

En länk är bara en pekare till en inod. En katalog är en inod som innehåller länkar. Varje filnamn i en katalog är bara en länk till en inod. Att öppna en fil i Unix skapar också en länk, men det är en annan typ av länk (det är inte en namngiven länk).

En hård länk är bara en extra katalogpost som pekar på den inoden. När du ls -l är numret efter behörigheterna namnet på länkantalet. De flesta vanliga filer har en länk. Att skapa en ny hårdlänk till en fil gör att båda filnamnen pekar på samma inod. Obs:

% 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 tydligt se att det inte finns något som heter en hård länk. En hård länk är densamma som ett vanligt namn. I exemplet ovan, test eller test2, vilken är originalfilen och vilken är den hårda länken? I slutet kan du inte verkligen berätta (även med tidsstämplar) eftersom båda namnen pekar på samma innehåll, samma 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 flagga till ls visar inodnummer i början av raden. Observera hur test test2 har samma inodenummer, men test3 har en annan.

Nu, om du fick gör detta för kataloger, två olika kataloger i olika punkter i filsystemet kan peka på samma sak. I själva verket kan en undermapp peka tillbaka till sin farförälder och skapa en slinga.

Varför är denna slinga ett problem ? För när du korsar finns det inget sätt att upptäcka att du slingrar (utan att hålla reda på inodnummer när du korsar). Tänk dig att du skriver kommandot du, som måste återgå genom subdirs för att ta reda på diskanvändning. Hur skulle du veta vem n det slog en slinga? Det är felbenäget och en hel del bokföring som du skulle behöva göra, bara för att ta bort den här enkla uppgiften.

Symlänkar är ett helt annat odjur, i att de är en speciell typ av ”fil” som många filfilsystems API: er tenderar att automatiskt följa. Observera att en symlänk kan peka på en icke-existerande destination, eftersom de pekar med namn och inte direkt till en inod. Det konceptet är inte meningsfullt med hårda länkar, eftersom bara existensen av en ”hård länk” betyder att filen finns.

Så varför kan du hantera symlänkar enkelt och inte hårda länkar? Vi kunde se ovan att hårda länkar inte kan särskiljas från normala katalogposter. Symlänkar är dock speciella, detekterbara och kan hoppas över! du märker att symlink är en symlink och hoppar över 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 snälla förklara mer om problemet med cykler med hårda länkar? Varför är det ok med symlänkar
• De verkar ha tillåtit det på Mac-datorer genom att lägga till cykeldetektering i länk () systemanropet och vägrar att låta dig skapa en kataloglänk om det skulle skapa en cykel . Verkar vara en rimlig lösning.
• @psusi mkdir -p a / b; nocheckln c a; mv c a / b; – nocheckln det finns en teoretisk ln som inte söker efter katalog args, och bara övergår till länk, och eftersom ingen cykel görs är vi alla bra på att skapa ’ c ’. sedan flyttar vi ’ c ’ till ’ a / b ’, och en cykel skapas från a / b / c – > a / – checka in länk () är inte tillräckligt bra
• Cykler är väldigt dåliga. Windows har detta problem med ” korsningar ” som är kataloger för hårda länkar. Om du av misstag tillämpar behörigheter för hela din profil avslöjar den en serie korsningar som skapar en oändlig cykel. Återkommande genom katalogerna återkommer tills väglängdsbegränsningar stoppar det.
• @WhiteWinterWolf, enligt den här länken lade de specifikt till stöd för det för tidsmaskin, men endast root får göra det: superuser.com/questions/360926/…

Du kan använda bindmontering för att simulera kataloger för hårda länkar

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

Med undantag för monteringspunkter har varje katalog en enda förälder: ...

Ett sätt att gör pwd är att kontrollera enheten: inode för ”.” och ”..”. Om de är desamma har du nått roten till filsystemet. Annars hittar du namnet på den aktuella katalogen i föräldern, trycker på den på en stack och börjar jämföra ”../.” med ”../ ..”, sedan ”../../.” med ”../../ ..”, etc. När du väl har träffat roten, börja poppa och skriva ut namnen från stacken. Denna algoritm är beroende av det faktum att varje katalog har en enda förälder.

Om hårda länkar till kataloger tillåts, vilken av de flera föräldrarna ska .. peka på? Det är en tvingande anledning till att hårdlänkar till kataloger inte är tillåtna. p>

Symlänkar till kataloger orsakar inte det problemet. Om ett program vill kan det göra en lstat() på varje del av sökvägen och upptäcka när en symlänk påträffas. pwd -algoritmen returnerar det verkliga absoluta sökvägen för en målkatalog. Det faktum att det finns en bit text någonstans (symlink) som pekar på målkatalogen är ganska irrelevant. Förekomsten av en sådan symlänk skapar inte en slinga i diagrammet.

Kommentarer

• Inte så säker på detta. Om vi tänker på .. som en slags virtuell hårdlänk till föräldern, finns det ingen teknisk anledning att målet för länken bara kan ha en annan länk till den. pwd måste bara använda en annan algoritm för att lösa sökvägen.

Inget av följande är den verkliga anledningen till att inte tillåta hårda länkar till kataloger; varje problem är ganska lätt att lösa:

• cykler i trädstrukturen orsakar svåra korsningar
• flera föräldrar, så vilken är den ”riktiga”?
• sopsamling av filsystem

verklig anledning (som antyds av @ Thorbjørn Ravn Andersen) kommer när du tar bort en katalog som har flera föräldrar, från katalogen pekad på av ..:

Vad ska .. nu peka på?

Om katalogen raderas från dess överordnade men dess länkantal är fortfarande större än 0 då måste det finnas något, någonstans som fortfarande pekar på det. Du kan inte låta .. peka på ingenting; många program förlitar sig på .., så systemet måste korsa hela filsystemet tills det hittar det första som pekar på den raderade katalogen, bara för att uppdatera ... Antingen det eller filsystemet måste ha en lista över alla kataloger som pekar på en hårdlänkad katalog.

Hur som helst, detta skulle vara en overhead och en extra komplikation för filsystemets metadata och / eller kod, så designarna bestämde sig för att inte tillåta det.

Kommentarer

• Att ’ också är lätt att lösa: hålla en lista över föräldrar till en barnkatalog, som du uppdaterar när du lägger till eller tar bort en länk till barnet. När du tar bort den kanoniska föräldern (barnets mål ’ s

  ), uppdatera .. för att peka på en av de andra föräldrarna i listan.

• Jag håller med. Inte raketvetenskap att lösa. Men ändå en prestandakostnad, och det skulle ta lite extra utrymme i filsystemets metadata och lägga till komplikationer. Och så gick designarna för det enkla, snabba tillvägagångssättet – don ’ t tillåt länkar till hårda kataloger.
• Sym-länkar till dirs ” bryter mot avgjort semantik och beteende ”, men ändå är de fortfarande tillåtna. Vissa kommandon behöver därför alternativ för att kontrollera om sym-länkar följs (t.ex. -L i find och cp). När ett program följer ’ .. ’ uppstår ytterligare förvirring, därav skillnaden i output från pwd och / bin / pwd efter att ha passerat en sym länk. Det finns inga ” Unix-svar ”; bara designbeslut. Den här kretsar kring vad som blir av ” .. ” som jag sade i mitt svar. Tyvärr är ’ .. ’ inte ’ t nämnde till och med i svaret att alla andra röstar så fårligt.
• BTW, jag ’ säger inte jag ’ m för hårda länkar till dirs. Inte alls. Jag vill inte ’ att mitt dagjobb ska vara svårare än det redan är.
• Det ’ är inte vad POSIX säger, men IMO ’ .. ’ borde aldrig ha varit ett filsystemskoncept, snarare löst syntaktiskt på banorna, så att a/.. skulle alltid betyda .. Så här fungerar webbadresser, btw. Det ’ är webbläsaren som ’ s löser ’ .. ’ innan den ens träffar servern. Och det fungerar bra.

Skapande av hårdlänkar i kataloger skulle inte kunna återställas. Antag att vi har:

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

Jag länkar det till /dir2.

Så /dir2 innehåller nu också alla dessa filer och kataloger

Vad händer om jag ändrar mig? Jag kan ”t bara rmdir /dir2 (eftersom det inte är tomt)

Och om jag rekursivt raderar i /dir2. .. det kommer att raderas från /dir1 också!

IMHO är det i stor utsträckning tillräcklig anledning för att undvika detta!

Redigera:

Kommentarer föreslår att du tar bort katalogen genom att göra rm på den .Men rm i en icke-tom katalog misslyckas, och detta beteende måste kvarstå, oavsett om katalogen är hårdlänkad eller inte. Så du kan ”t bara rm för att ta bort länken. Det skulle kräva ett nytt argument för att rm, bara för att säga” om katalogen inod har ett referensantal> 1, koppla sedan bara bort katalogen ”.

Vilket i sin tur bryter en annan princip av minst överraskning: det betyder att borttagning av en kataloghårdlänk som jag just skapade inte är densamma som borttagning för en normal fil-hårdlänk …

Jag kommer att omformulera min mening: Utan vidare utveckling skulle skapandet av hårdlänk vara oåterkallelig (eftersom inget aktuellt kommando kunde hantera borttagningen utan att vara osammanhängande med nuvarande beteende)

Om vi tillåter mer utveckling för att hantera ärendet, antalet fallgropar och risken för dataförlust om du ”är inte tillräckligt medvetna om hur systemet fungerar, vilket en sådan utveckling innebär, är IMHO en tillräcklig anledning för att begränsa hårdlänkning i kataloger.

Kommentarer

• Det borde inte vara ett problem. När du skapar hardlink till dir2 måste vi göra hardlink till allt innehåll i dir1, så om vi byter namn på eller tar bort dir2 raderas bara en extra länk till inoden. Och det borde inte påverka dir1 och dess innehåll eftersom det finns minst en länk (dir1) till inoden.
• Ditt argument är felaktigt. Du skulle bara ta bort länken, inte göra rm -rf. Och om länkantalet når 0, vet systemet att det också kan ta bort allt innehåll.
• Att ’ är mer eller mindre allt rm gör det under alla omständigheter (ta bort länken). Se: unix.stackexchange.com/questions/151951/… Det här är verkligen inte ’ t ett problem, mer än med hårdlänkade filer. Att ta bort länken tar bara bort den nämnda referensen och minskar antalet länkar. Det faktum att rmdir vann ’ att ta bort icke-tomma kataloger är irrelevant – det skulle inte vara ’ t gör det för dir1 antingen. Hårdlänkar är inte ’ t är kopior av data, de är samma faktiska fil, alltså ” tar bort ” dir2-filen skulle radera kataloglistan för dir1. Du måste alltid ta bort länken.
• Du kan ’ t bara ta bort länken som en vanlig fil, för rm i en katalog don ’ t ta bort länken om den ’ inte är tom. Se Redigera.

Detta är en bra förklaring. När det gäller ”Vilken av flera föräldrar ska .. peka på?” en lösning skulle vara för en process att bibehålla sin fulla wd-väg, antingen som inoder eller som en sträng. inoder skulle vara mer robusta eftersom namn kan ändras. Åtminstone i gamla tider fanns det en inodkod för varje öppen fil som ökades när en fil öppnades, minskad när den stängdes. När den nollade nollades den och lagringen som den pekade på skulle frigöras. När filen inte längre var öppen av någon skulle den (The in-core copy) överges. Detta skulle bibehålla banan som giltig om någon annan process flyttade en katalog till en annan katalog medan underkatalogen var i sökvägen till en annan process. På samma sätt som hur du kan ta bort en öppen fil men den tas helt enkelt bort från katalogen, men ändå öppen för alla processer som har den öppen.

Hårlänkande kataloger var tidigare fritt tillåtna i Bell Labs UNIX, åtminstone V6 och V7, vet inte om Berkeley eller senare. Ingen flagga krävs. Kan du göra öglor? Ja, gör det inte. Det är mycket tydligt vad du gör om du gör en slinga. I övrigt bör du öva på att knyta dig runt nacken medan du väntar på att det ska bli fallskärm ur ett plan om du har den andra änden bekvämt hängd i en krok på huvudhuvudet.

Vad Jag hoppades att göra med det idag var att länka hem hem till mig så att jag kunde ha / hem / administratör tillgänglig oavsett om / hem var täckt med en automout över hemmet, den bilen hade en symlänk som heter administratör till / lhome / administ. Detta gör det möjligt för mig att ha ett administratörskonto som fungerar oavsett tillståndet för mitt primära hemfilsystem. Detta ÄR ett experiment för linux, men jag tror att jag lärde mig en gång för UCB-baserade SunOS att automatiskt görs på ascii-strängnivå. Det är svårt att se hur de skulle kunna göras annars som ett lager ovanpå någon godtycklig FS.

Jag läste det någon annanstans. och .. är inte heller filer längre i katalogen. Jag är säker på att det finns goda skäl till allt detta, och att mycket av det vi tycker om (såsom att kunna montera NTFS) är möjligt på grund av sådana saker, men en del av UNIX: s elegans var i implementeringen.Det är fördelarna som generalitet och smidighet som denna elegans tillhandahåller som har gjort det möjligt för den att vara så robust och uthärda i fyra decennier. När vi förlorar de eleganta implementeringarna kommer det så småningom att bli som Windows (jag hoppas att jag har fel!). Någon skulle då skapa ett nytt operativsystem som bygger på eleganta principer. Något att tänka på. Jag kanske har fel, jag är inte (uppenbarligen) bekant med det nuvarande genomförandet. Det är fantastiskt men hur användbar 30 år gammal förståelse är för Linux … för det mesta!

Kommentarer

• Jag tror, även om jag kan ha fel, att . och .. inte är hårda länkar i filsystemet, för moderna filsystem. Men filsystemets drivrutin förfalskar dem. Det är dessa filsystem som stoppar kataloger som länkar hårt. För gamla filsystem var det möjligt (men farligt). För att göra det du försöker, se på mount --bind, se även mount --make… och kanske behållare.

Från vad jag samlar är den främsta anledningen att det är användbart att kunna ändra katalognamn utan att förstöra körande program som använder deras arbetskatalog för att referera till andra filer. Antag att du använde Wine för att köra ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe och att du ville flytta hela prefixet till ~/.wine istället. Om Firefox av någon märklig anledning hade tillgång till drive_c/windows genom att hänvisa till ../../windows, byter namn på ~/.newwineprefix implementeringar av .. som håller reda på överordnad katalog som en textsträng istället för en inod.

Att lagra inoden för en enstaka förälderkatalog måste vara enklare än att försöka för att hålla reda på varje sökväg som både en textsträng och en serie inoder.

En annan anledning är att han misshandlar ng-applikationer kan kanske skapa loopar. Uppförande av applikationer bör kunna kontrollera om inoden för katalogen som flyttas är densamma som inoden för någon av kapslade kataloger den flyttas till, precis som du inte kan flytta en katalog till sig själv, men detta kanske inte verkställs på filsystemnivå.

Ytterligare en anledning kan vara att om du kunde länka kataloger skulle du vilja förhindra att länka en katalog som du inte kunde ändra. find har säkerhetsöverväganden eftersom det används för att rensa filer som skapats av andra användare från tillfälliga kataloger, vilket kan orsaka problem om en användare byter en riktig katalog för en symlänk medan find åberopar ett annat kommando. Att kunna länka viktiga kataloger skulle tvinga en administratör att lägga till extra tester till find för att undvika att påverka dem. (Ok, du redan kan inte göra detta för filer, så den här anledningen är ogiltig.)

Ytterligare en anledning är att lagring av överordnad katalogens inod kan ge extra redundans vid filsystemskada eller skada. ville att .. skulle lista alla överordnade kataloger som är hårddisk till den här, så en annan, godtycklig förälder kan lätt hittas om den nuvarande är avmarkerad, inte bara bryter du mot idén att länkar är lika, måste du ändra hur filsystemet lagrar och använder inoder. Att ha program behandlar sökvägar som en serie (uniq ue till varje hårdlänk) av kataloginoder skulle undvika detta, men du skulle inte få redundansen vid skador på filsystemet.