Miksi kovat linkit hakemistoihin eivät ole sallittuja UNIX / Linuxissa?

Tämä on vain huono idea, koska ei ole mitään tapaa erottaa kovan linkin ja alkuperäisen nimen välistä eroa.

Jos sallit kovien linkkien hakemistoihin, se rikkoo tiedostojärjestelmän suunnatun asyklisen kaaviorakenteen, luoden mahdollisesti hakemistosilmukoita ja roikkuvia hakemiston alipuita, mikä tee fsck ja muiden tiedostopuiden kävelijöille virheiden altis.

Ensinnäkin, ymmärtääksemme tämän, puhutaan ”inodeista”. Tiedostojärjestelmän tiedot säilytetään levyllä olevat lohkot ja nämä lohkot kerää yhteen inodi. Voit ajatella inodia THE-tiedostona. Inodeista puuttuu kuitenkin tiedostonimi. Siihen linkit tulevat.

Linkki on vain osoitin inodille. Hakemisto on inodi, joka pitää linkkejä. Jokainen hakemiston tiedostonimi on vain linkki inodiin. Tiedoston avaaminen Unixissa luo myös linkin, mutta se on erityyppinen linkki (se ei ole nimetty linkki).

Kova linkki on vain ylimääräinen hakemistomerkintä, joka osoittaa kyseiselle inodille. Kun ls -l, käyttöoikeuksien jälkeinen numero on nimetty linkkien määrä. Useimmilla tavallisilla tiedostoilla on yksi linkki. Uuden kovan linkin luominen tiedostoon saa molemmat tiedostonimet osoittamaan samaa inodia. Huomaa:

% 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 

Nyt voit selvästi nähdä, että kovaa linkkiä ei ole olemassa. Kova linkki on sama kuin tavallinen nimi. Yllä olevassa esimerkissä test tai test2, mikä on alkuperäinen tiedosto ja mikä on kova linkki? Loppuun mennessä et voi todellakaan kertoa (edes aikaleimojen mukaan), koska molemmat nimet viittaavat samaan sisältöön, samaan inodiin:

% 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 lippu ls näyttää inodinumerot rivin alussa. Huomaa, miten test ja test2: llä on sama inodinumero, mutta test3: llä on toinen numero.

Jos sinulla olisi lupa tee tämä hakemistoille, kaksi eri hakemistoa tiedostojärjestelmän eri kohdissa voivat viitata samaan asiaan. Itse asiassa alihakemisto voi osoittaa takaisin isovanhempaansa luomalla silmukan.

Miksi tämä silmukka on huolestuttava ? Koska matkalla ei ole mitään tapaa havaita, että olet silmukannut (ilman että pidät kirjaa inodinumeroista kulkiessasi). Kuvittele, että kirjoitat du -komennon, jonka on toistuvasti aliryhmien kautta saadaksesi selville levyn käytöstä. Mistä du tietää mistä n se osui silmukkaan? du: n on tehtävä virheitä ja paljon kirjanpitoa, vain vetääkseen tämän yksinkertaisen tehtävän.

Symlinkit ovat aivan erilainen peto, että ne ovat erityinen ”tiedosto”, jota monet tiedostotiedostojärjestelmän sovellusliittymät yleensä seuraavat automaattisesti. Huomaa, että symboli voi osoittaa olemattomaan kohteeseen, koska se osoittaa nimen perusteella eikä suoraan inodiin. Käsitteellä ei ole merkitystä kovien linkkien kanssa, koska pelkkä ”kovan linkin” olemassaolo tarkoittaa, että tiedosto on olemassa.

Miksi du voi käsitellä Symlinkit helposti ja eivät kovia linkkejä? Ymmärsimme edellä, että kovat linkit eivät ole erotettavissa tavallisista hakemistomerkinnöistä. Symlinkit ovat kuitenkin erityisiä, havaittavia ja ohitettavia! du huomaa, että symlink on symlinkki ja ohittaa sen kokonaan!

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

Kommentit

• Allowing hard links to directories would break the directed acyclic graph structure of the filesystem.Voitteko selittää lisää kiertolinkkien ongelmasta? Miksi symlinkeillä on ok
• He näyttävät sallineen sen Macissa lisäämällä jaksotunnistuksen linkki () -järjestelmäkutsuun ja kieltäytymästä sallimasta luoda hakemiston kovaa linkkiä, jos se loisi jakson . Vaikuttaa kohtuulliselta ratkaisulta.
• @psusi mkdir -p a / b; nocheckln c a; mv c a / b; – nocheckln on teoreettinen ln, joka ei tarkista hakemistojen argumentteja ja vain siirtyy linkittämiseen, ja koska jaksoa ei tehdä, olemme kaikki hyviä luomaan ’ c ’. sitten siirrämme ’ c ’ osastoon ’ a / b ’, ja a / b / c: stä luodaan sykli – > a / – linkin tarkistaminen () ei ole tarpeeksi hyvä
• Syklit ovat erittäin huonoja. Windowsilla on tämä ongelma ” -liitosten ” kanssa, jotka ovat kovan linkin hakemistoja. Jos vahingossa käytät käyttöoikeuksia koko profiiliisi, se paljastaa sarjan risteyksiä, jotka luovat äärettömän jakson. Hakemistojen toistaminen toistuu, kunnes polun pituusrajoitukset estävät sen.
• @WhiteWinterWolf, tämän linkin mukaan he lisäsivät siihen nimenomaan tukea aikakoneelle, mutta vain root saa tehdä sen: superuser.com/questions/360926/…

Sitomisen avulla voit simuloida kovan linkityksen hakemistoja

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

Kiinnityspisteitä lukuun ottamatta jokaisessa hakemistossa on yksi ainoa vanhempi: ...

Yksi tapa do pwd on tarkistaa laite: inode ”.” ja ”..”. Jos ne ovat samat, olet saavuttanut tiedostojärjestelmän juuren. Muussa tapauksessa etsi nykyisen hakemiston nimi ylätasolta, työnnä se pinoon ja aloita ”../” -vertailua. painamalla ”../ ..” ja sitten ”../../.” ”../../ ..” jne. kanssa. Kun olet päässyt päähakemistoon, aloita popping ja tulosta nimiä pinosta. Tämä algoritmi perustuu siihen tosiasiaan, että jokaisessa hakemistossa on yksi ja vain yksi ylätaso.

Jos sallitut linkit hakemistoihin, mihin toisen vanhemmista .. tulisi osoittaa? Se on yksi pakottava syy siihen, miksi linkkejä hakemistoihin ei sallita.

Linkit hakemistoihin eivät aiheuta ongelmaa. Jos ohjelma haluaa, se voi tehdä lstat() polun nimen jokaiselle osalle ja havaita, kun symboli esiintyy. pwd -algoritmi palauttaa kohdehakemiston todellisen absoluuttisen polun nimen. Se, että jossakin tekstikappale (symlink) on kohdehakemistoon, on melko merkityksetöntä. Tällaisen symlinkin olemassaolo ei luo silmukkaa kaavioon.

Kommentit

• Ei niin varma tästä. Jos ajattelemme .. olevan eräänlainen virtuaalinen kovalinkki vanhempaan, ei ole mitään teknistä syytä, että linkin kohteella voi olla vain yksi muu linkki siihen. pwd olisi vain käytettävä eri algoritmia polun ratkaisemiseen.

Mikään seuraavista ei ole todellinen syy kieltää linkit hakemistoihin; jokainen ongelma on melko helppo ratkaista:

• puurakenteen syklit aiheuttavat vaikeita kulkemisia
• useita vanhempia, joten mikä on ”todellinen”?
• tiedostojärjestelmän roskien keräys

todellinen syy (@ Thorbjørn Ravn vihjaa) Andersen) tulee, kun poistat hakemiston, jossa on useita vanhempia, hakemistosta, johon :

Mihin .. pitäisi nyt osoittaa?

Jos hakemisto poistetaan vanhemmalta, mutta sen linkkien määrä on edelleen suurempi kuin 0, silloin jotain on oltava, jossain edelleen osoittamassa sitä. Et voi jättää .. osoittamaan mitään; monet ohjelmat luottavat .. -ohjelmaan, joten järjestelmän on kuljettava koko tiedostojärjestelmä , kunnes se löytää ensimmäisen poistettuun hakemistoon osoittavan asian vain päivittääksesi ... Joko tämän tai tiedostojärjestelmän olisi pidettävä yllä luetteloa kaikki hakemistot, jotka osoittavat linkitettyyn hakemistoon.

Kummassakin tapauksessa tämä olisi suorituskyvyn yläpuolella ja ylimääräinen komplikaatio tiedostojärjestelmän metatiedoille ja / tai koodille, joten suunnittelijat päättivät olla sallimatta sitä.

Kommentit

• Se, että ’ on myös helppo ratkaista: pidä luetteloa lapsihakemiston vanhemmista, jonka päivität, kun lisäät tai poistat linkin lapselle. Kun poistat ensisijaisen vanhemman (lapsen kohde ’ s

  ), päivitä .. osoittamaan yhtä luettelon vanhemmista.

• Olen samaa mieltä. Ei rakettitiedettä ratkaistavaksi. Siitä huolimatta suorituskyky, ja se vie hieman ylimääräistä tilaa tiedostojärjestelmän metatiedoissa ja lisäisi komplikaatioita. Joten suunnittelijat valitsivat yksinkertaisen ja nopean lähestymistavan – älä ’ salli linkkejä koviin hakemistoihin.
• Sym-linkit dirs ” rikkovat vakiintunutta semantiikkaa ja käyttäytymistä ”, mutta ne ovat silti sallittuja. Jotkut komennot tarvitsevat siis vaihtoehtoja sym-linkkien seuraamiseksi (esim. -L etsinnässä ja cp). Kun ohjelma seuraa ’. sym-linkki. ” Unix-vastauksia ei ole ”; vain suunnittelupäätökset. Tämä pyörii siitä, mitä ” .. ” tulee, kuten totesin vastauksessani. Valitettavasti ’ .. ’ ei ’ edes maininnut vastauksessa, että kaikki muut äänestää niin kiihkeästi.
• BTW, en ’ en sano, että

Hakemistojen kovan linkin luominen olisi peruuttamatonta. Oletetaan, että meillä on:

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

Linkitän sen kovasti linkkiin /dir2.

Joten /dir2 sisältää nyt myös kaikki nämä tiedostot ja hakemistot.

Entä jos muutan mieltäni? En voi ”t just rmdir /dir2 (koska se ei ole tyhjä)

Ja jos poistan rekursiivisesti ryhmässä /dir2. .. se poistetaan myös kohdasta /dir1!

IMHO se on suureksi osaksi syytä välttää tämä!

Muokkaa:

Kommentit suosittelevat hakemiston poistamista tekemällä rm siihen .Mutta rm ei-tyhjässä hakemistossa epäonnistuu, ja tämän käyttäytymisen on pysyttävä riippumatta siitä, onko hakemisto linkitetty vai ei. Joten voit ”t vain rm linkityksen poistamiseksi. Se vaatii uuden argumentin rm, vain sanomaan” jos hakemisto inode on viitemäärä> 1, poista sitten vain hakemiston linkitys ”.

Tämä puolestaan rikkoo toisen vähiten yllätetyn periaatteen: se tarkoittaa, että juuri luomani hakemiston kovan linkin poisto ei ole sama kuin poistaminen normaalin tiedoston kovalinkistä …

Sanon lauseeni uudelleen: Ilman jatkokehitystä kovan linkin luominen olisi peruuttamatonta (koska mikään nykyinen komento ei pystyisi käsittelemään poistoa olematta epäjohdonmukainen nykyisen käyttäytymisen kanssa)

Jos annamme enemmän kehitystä tapauksen käsittelemiseksi, sudenkuoppien määrä ja tietojen menetysriski jos ”En ole tarpeeksi tietoinen järjestelmän toiminnasta, tällainen kehitys merkitsee, onko IMHO riittävä syy rajoittaa hakemistojen kovaa linkitystä.

Kommentit

• Sen ei pitäisi olla ongelma. Sinun tapauksessasi, kun luomme kovan linkin dir2: een, meidän on tehtävä hardlink kaikkiin dir1: n sisältöihin, joten jos nimämme tai poistamme dir2: n, vain ylimääräinen linkki inodiin poistetaan. Ja sen ei pitäisi vaikuttaa dir1: ään ja sen sisältöön, koska ainakin yksi linkki (dir1) inodiin on olemassa.
• Väitteesi on väärä. Voit vain purkaa sen linkityksen, et tehdä rm -rf. Ja jos linkkien määrä saavuttaa nollan, järjestelmä tietäisi, että se voi poistaa myös kaiken sisällön.
• Että ’ s enemmän tai vähemmän kaikki rm toimii joka tapauksessa alla (poista linkitys). Katso: unix.stackexchange.com/questions/151951/… Tämä ei todellakaan ole ’ t ongelma, enempää kuin kovalla linkillä olevien tiedostojen kanssa. Linkityksen purkaminen poistaa nimetyn viitteen ja vähentää linkkien määrää. Sillä, että rmdir voitti ’ ei tyhjiä hakemistoja, ei ole merkitystä – se ei ’ t tee se myös dir1. Kova linkit eivät ole ’ t kopioita tiedoista, ne ovat sama todellinen tiedosto, joten ” poistetaan ” dir2-tiedosto pyyhkii hakemistoluettelon dir1: lle. Sinun on aina irrotettava linkitys.
• Voit ’ t vain purkaa linkityksen tavallisen tiedoston tavoin, koska rm hakemistossa älä ’ t poista linkitys, jos se ’ ei ole tyhjä. Katso Muokkaa.

Tämä on hyvä selitys. Mitä ”monen vanhemman pitäisi .. osoittaa?” yksi ratkaisu olisi, että prosessi ylläpitää täyttä wd-polkua joko inodeina tai merkkijonona. inodes olisi vankempi, koska nimiä voidaan muuttaa. Ainakin vanhoina aikoina jokaisessa avoimessa tiedostossa oli ytimen sisäinen inodi, jota lisättiin aina, kun tiedosto avattiin, vähennettiin suljettuna. Kun se saavuttaa nollan, se ja varastotila, johon se osoitti, vapautuu. Kun kukaan ei enää voinut avata tiedostoa, se (Sisäinen kopio) hylättiin. Tämä säilyttäisi polun kelvollisena, jos jokin muu prosessi siirtäisi hakemiston toiseen hakemistoon, kun alihakemisto oli toisen prosessin polulla. Samoin kuin voit poistaa avoimen tiedoston, mutta se yksinkertaisesti poistetaan hakemistosta, mutta silti avoin kaikille prosesseille, joilla se on auki.

Kova linkityshakemistot olivat aiemmin vapaasti sallittuja Bell Labs UNIX -ohjelmassa, ainakin V6 ja V7, älä tiedä Berkeleystä tai uudemmasta. Lippua ei vaadita. Voisitko tehdä silmukoita? Kyllä, älä tee sitä. On hyvin selvää, mitä teet, jos teet silmukan. Pitäisikö sinun harjoitella solmun sitomista kaulasi ympärillä odottaessasi vuoroasi laskuvarjoon lentokoneesta, jos toinen pää on kätevästi ripustettu koukkuun irtotavaran päähän.

Mitä Toivon, että tekisin sen tänään, että linkin koti kotiin kovalla tavalla, jotta minulla olisi / koti / järjestelmänvalvoja käytettävissä riippumatta siitä, peitettiinkö / koti vai ei, koti peitettiin kotona olevalla automaatilla. / lhome / administ. Tämän ansiosta saan järjestelmänvalvojan tilin, joka toimii ensisijaisen kotitiedostojärjestelmän tilasta riippumatta. Tämä ON on Linux-kokeilu, mutta luulen UCB-pohjaisen SunOS: n oppineen kerralla, että automaattiset asennukset tehdään ascii-merkkijonotasolla. On vaikea nähdä, miten ne voitaisiin tehdä muuten kerroksena minkä tahansa mielivaltaisen FS: n päälle.

Luin muualla. ja .. eivät ole enää tiedostoja myöskään hakemistossa. Olen varma, että kaikella on hyvät syyt, ja että suuri osa nautinnostamme (kuten NTFS: n asentaminen) on mahdollista tällaisten asioiden takia, mutta osa UNIX: n eleganssista oli toteutuksessa.Tämän tyylikkyyden tarjoamat edut, kuten yleisyys ja muovattavuus, ovat mahdollistaneet sen olevan niin kestävä ja kestävä neljän vuosikymmenen ajan. Kun menetämme tyylikkäät toteutukset, siitä tulee lopulta kuin Windows (toivon, että olen väärässä!). Joku loisi sitten uuden käyttöjärjestelmän, joka perustuu tyylikkäisiin periaatteisiin. Jotain ajateltavaa. Ehkä olen väärässä, en ole (ilmeisesti) perehtynyt nykyiseen toteutukseen. Se on hämmästyttävää, kuinka sovellettava 30-vuotias ymmärrys on Linuxissa … suurimman osan ajasta!

Kommentit

• Luulen, että vaikka olenkin väärässä, . ja .. eivät ole kovia linkkejä tiedostojärjestelmässä, nykyaikaisissa tiedostojärjestelmissä. Tiedostojärjestelmäohjain kuitenkin väärentää ne. Nämä tiedostojärjestelmät pysäyttävät hakemistojen linkittämisen. Vanhoille tiedostojärjestelmille se oli mahdollista (mutta vaarallista). Jos haluat tehdä mitä yrität, katso mount --bind, katso myös mount --make… ja ehkä kontteja.

Keräämieni tietojen perusteella tärkein syy on se, että on hyödyllistä pystyä vaihtamaan hakemistojen nimiä sekoittamatta käynnissä olevia ohjelmia, jotka käyttävät työhakemisto viittaamaan muihin tiedostoihin. Oletetaan, että käytit Wine-ohjelmaa ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe ajamiseen ja halusit siirtää koko etuliitteen kohtaan ~/.wine. Jos jostakin outosta syystä Firefox käytti drive_c/windows -sivustoa viittaamalla ../../windows -nimeykseen, nimeämällä ~/.newwineprefix -katkokset uudelleen .. -toteutukset, jotka seuraavat päähakemistoa tekstimerkkinä inodin sijaan.

Yksittäisen vanhemman hakemiston inodin tallentamisen on oltava yksinkertaisempaa kuin yrittää seurata jokaista polkua sekä tekstimerkkijonona että sarjana inodeja.

Toinen syy on väärinkäyttäytyminen ng sovellusta voi pystyä luomaan silmukoita. Käyttäytyvien sovellusten pitäisi pystyä tarkistamaan, onko siirrettävän hakemiston inode sama kuin minkä tahansa sisäkkäisten hakemistojen inode, johon se siirretään, samoin kuin et voi siirtää hakemistoa itseensä, mutta tämä ei välttämättä pakoteta tiedostojärjestelmätasolla.

Vielä yksi syy voi olla se, että jos voisit hakemistoilla linkittää kovaa linkkiä, haluat estää sellaisten hakemistojen kovan linkityksen, joita et voi muokata. find: llä on turvallisuusnäkökohtia, koska sitä käytetään muiden käyttäjien luomien tiedostojen tyhjentämiseen väliaikaisista hakemistoista, mikä voi aiheuttaa ongelmia, jos käyttäjä vaihtaa oikean hakemiston symlinkille, kun find kutsuu toista komentoa. Jos pystyt linkittämään tärkeät hakemistot, järjestelmänvalvoja pakotettaisiin lisäämään ylimääräisiä testejä ryhmään find välttääkseen niihin vaikuttamasta. (Ok, olet jo ei voi tehdä tätä tiedostoille, joten tämä syy on virheellinen.)

Vielä yksi syy on, että päähakemiston inodin tallentaminen voi tarjota ylimääräistä redundanssia tiedostojärjestelmän vioittumisen tai vahingoittumisen yhteydessä. Jos halusi .. luetella kaikki vanhemmat hakemistot, jotka linkittävät tähän hakemistoon, joten erilainen, mielivaltainen vanhempi voitaisiin helposti löytää, jos nykyinen linkki poistetaan, et vain rikkoa kovasti ajatusta linkit ovat tasa-arvoisia, sinun on muutettava, miten tiedostojärjestelmä tallentaa ja käyttää inodeja. Ohjelmien saaminen käsittelee polkuja sarjana (uniq hakemiston inodien kullekin kovalle linkille) välttäisi tämän, mutta et turhautaisi tiedostojärjestelmävahinkoja.