Miért nem engedélyezettek a könyvtárakhoz való hard linkek a UNIX / Linux rendszerben?

Ez csak egy rossz ötlet, mivel nem képes megkülönböztetni a merevlemezt és az eredeti nevet.

A könyvtárakhoz való kemény linkek engedélyezése megszakítaná a fájlrendszer irányított aciklikus gráfstruktúráját, esetleg könyvtárhurkok létrehozását és függő könyvtárfák létrehozását, ami tegye fsck és minden más fájfa-járó hibára való hajlandóságot.

Először ennek megértéséhez beszéljünk az inodes-ről. A fájlrendszer adatait blokkokat a lemezen, és ezeket a blokkokat egy inode gyűjti össze. Az inode-t úgy gondolhatja, mint THE fájlt. Az inode-okból azonban hiányoznak a fájlnevek. Itt jönnek be a linkek.

A link csak egy inode mutatója. A könyvtár egy olyan inode, amely linkeket tartalmaz. A könyvtár minden fájlneve csak egy link egy inode-hoz. Ha megnyit egy fájlt a Unix-ban, létrehoz egy linket is, de ez egy más típusú hivatkozás (nem egy megnevezett link).

A hard link csak egy extra könyvtárbejegyzés, amely az adott inode-ra mutat. Amikor ls -l, az engedélyek utáni szám a megnevezett linkek száma. A legtöbb rendes fájlnak egy linkje lesz. Ha új fájlra mutató linket hoz létre, akkor mindkét fájlnév ugyanazon inode-ra mutat. Megjegyzés:

% 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 

Most már egyértelműen láthatja, hogy nem létezik kemény link. A kemény link megegyezik a szokásos névvel. A fenti példában test vagy test2 melyik az eredeti fájl és melyik a merevlemez? A végére nem lehet igazán megmondani (még időbélyegzőkkel sem), mert mindkét név ugyanazon tartalomra mutat, ugyanaz az 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 

A -i flag to ls inode számokat jelenít meg a sor elején. Vegye figyelembe, hogy test és A test2 azonos inode-számmal rendelkezik, de a test3 -nek más a száma.

Most, ha megengedték, hogy tegye ezt könyvtárak esetén, a fájlrendszer különböző pontjain található két különböző könyvtár ugyanarra mutathat. Valójában az alkönyvtár visszahúzhat a nagyszülőhöz, létrehozva egy ciklust.

Miért aggályos ez a hurok ? Mivel utazás közben nincs mód arra, hogy észlelje a hurkolást (anélkül, hogy nyomon követné az inode-számokat, amikor halad). Képzelje el, hogy a du parancsot írja, amelynek visszatér a alcsoportokhoz, hogy megtudja a lemezhasználatot. Hogyan tudhatná meg a du n elért egy hurkot? Hibára hajlamos és sok könyvelést kell tennie du, csak azért, hogy elhúzza ezt az egyszerű feladatot.

A Symlinkek egészen más fenevadak, hogy egy speciális típusú “fájlról” van szó, amelyet sok fájl fájlrendszer API automatikusan követ. Ne feledje, hogy a symlink egy nem létező rendeltetési helyre mutathat, mivel név szerint mutatnak, és nem közvetlenül az inódra. Ennek a fogalomnak nincs értelme a hard linkeknél, mert a “hard link” puszta létezése azt jelenti, hogy a fájl létezik.

Miért du tud foglalkozni ezzel a linkek könnyen és nem a linkek? Fentebb láthattuk, hogy a hard linkek nem különböztethetők meg a normál könyvtár bejegyzésektől. A szimlinkek azonban különlegesek, detektálhatók és átugorhatók! du észreveszi, hogy a A symlink egy symlink, és teljesen kihagyja!

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

Megjegyzések

• Allowing hard links to directories would break the directed acyclic graph structure of the filesystem.Kérem, magyarázza el részletesebben a ciklusok problémáját a kemény linkek segítségével? Miért rendben van a szimplainkkal
• Úgy tűnik, engedélyezték Mac-eken, ha ciklusérzékelést adtak a link () rendszerhíváshoz, és megtagadták, hogy címtár-linket hozzon létre, ha ciklust hozna létre. . Ésszerű megoldásnak tűnik.
• @psusi mkdir -p a / b; nocheckln c a; mv c a / b; – A nocheckln van egy elméleti ln, amely nem ellenőrzi a könyvtár argeket, és csak átmegy a linkelésre, és mivel ciklus nem készül, mindannyian jók vagyunk a ‘ c ‘. akkor ‘ c ‘ áthelyezzük ‘ a / b ‘, és a / b / c ciklus jön létre – > a / – a link () ellenőrzése nem elég jó
• A ciklusok nagyon rosszak. A Windows-nak ez a problémája van a ” csomópontokkal “, amelyek hard link könyvtárak. Ha véletlenül engedélyeket alkalmaz az egész profiljára, az olyan csomópontok sorozatát tárja fel, amelyek végtelen ciklust hoznak létre. A könyvtárakban való visszatérés addig ismétlődik, amíg az útvonal-korlátozások le nem állítják.
• @WhiteWinterWolf, ezen link szerint kifejezetten hozzáadtak támogatást az időgéphez, de ezt csak a root teheti meg: superuser.com/questions/360926/…

A bind mount segítségével szimulálhatja a kemény linkelő könyvtárakat

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

A csatlakozási pontok kivételével minden könyvtárnak egyetlen szülője van: ...

A do pwd az eszköz: inode “” ellenőrzésére szolgál. és “..”. Ha azonosak, akkor elérte a fájlrendszer gyökerét. Ellenkező esetben keresse meg az aktuális könyvtár nevét a szülőben, tolja azt a veremre, és kezdje el összehasonlítani a “../” szót. a “../ ..”, majd a “../../.” a “../../ ..” stb. használatával. Miután elérte a gyökérzetet, kezdje el kipattintani és kinyomtatni a neveket a veremből. Ez az algoritmus arra a tényre támaszkodik, hogy minden könyvtárnak csak egy szülője van. p>

Ha engedélyezték a címtárakhoz való hivatkozásokat, akkor a többszülősek egyikére .. melyikre kell mutatnia? Ez egy olyan kényszerítő ok, amely miatt a címtárakra mutató hivatkozások nem engedélyezettek.

A címtárakra mutató hivatkozások nem okoznak ilyen problémát. Ha egy program akarja, akkor megtehet egy lstat() t az útvonal minden részén, és észlelheti, ha szimbolikus linkre kerül. A pwd algoritmus visszaadja a célkönyvtár valódi abszolút útnevét. Az a tény, hogy van valahol egy szövegdarab (a symlink), amely a célkönyvtárra mutat, nagyjából lényegtelen. Egy ilyen symlink megléte nem hoz létre hurokot a grafikonon.

Megjegyzések

• Ebben nem annyira biztos. Ha úgy gondoljuk, hogy az .. egyfajta virtuális hardlink a szülőhöz, nincs technikai ok arra, hogy a link célpontjának csak egy másik linkje lehet. pwd csak más algoritmust kellene használnia az útvonal feloldására.

Az alábbiak egyike sem a valódi oka annak, hogy megtagadjuk a címtárakhoz való kemény linkeket; minden problémát meglehetősen könnyű megoldani:

• a fa szerkezetének ciklusai nehéz átjárást okoznak
• több szülő, tehát melyik az „igazi”?
• fájlrendszer szemétgyűjtése

A valódi ok (@ Thorbjørn Ravn utalt rá) Andersen) akkor jön, amikor töröl egy könyvtárat, amelynek több szülője van, abból a könyvtárból, amelyre :

Mire mutasson most az ..?

Ha a könyvtár törlődik a szülőjéből, de a linkek száma még mindig nagyobb, mint 0, akkor valaminek lennie kell, valahol még mindig rámutat. Nem hagyhatja a .. -t semmire sem mutatva; sok program támaszkodik az .. -re, így a rendszernek át kell haladnia a a teljes fájlrendszer ig, amíg meg nem találja az elsőt, amely a törölt könyvtárra mutat, csak az .. frissítéséhez. Vagy ennek, vagy a fájlrendszernek karban kell tartania a minden könyvtár, amely egy merevhivatkozású könyvtárra mutat.

Akárhogy is, ez egy teljesítménybeli általános költség és egy extra komplikáció a fájlrendszer metaadatainak és / vagy kódjának, ezért a tervezők úgy döntöttek, hogy nem engedélyezik.

Megjegyzések

• Ez ‘ is könnyen megoldható: vezessen egy gyermekkönyv szüleinek listáját, amelyet frissít, amikor hozzáad vagy eltávolít egy linket a gyermekhez. Ha törli a kanonikus szülőt (a gyermek célpontja ‘ s

  ), frissítse az .. elemet, hogy a listában lévő többi szülő valamelyikére mutasson.

• Egyetértek. Nem rakéta tudomány megoldani. De ettől függetlenül a teljesítmény általános költsége, és egy kis plusz helyet foglalna el a fájlrendszer metaadataiban, és bonyolultabbá tenné. Így a tervezők az egyszerű, gyors megközelítést választották – ne engedje, hogy linkek legyenek a kemény könyvtárakhoz.
• A Sym linkek a dirs sérti a megszokott szemantikát és viselkedést “, mégis megengedettek. Egyes parancsoknak ezért opciókra van szükségük a sym-linkek követésének vezérléséhez (pl. -L a keresésben és a cp). Ha egy program követi a következőt: ‘ .. ‘, akkor további zavart okoz, ezért a pwd és / bin / pwd kimenetében különbség van a sym link. Nincsenek ” Unix válaszok “; csak tervezési döntések. Ez körül forog, mi lesz ” .. “, ahogy válaszomban kijelentettem. Sajnos ‘ .. ‘ nem ‘ még a válaszban sem említette, hogy mindenki más ennyire szégyenkezve szavaz.
• BTW, nem ‘ nem mondom, hogy I ‘ m a hard linkek mellett hogy dirs. Egyáltalán nem. Nem ‘ nem akarom, hogy a napi munkám nehezebb legyen, mint amilyen már.
• Ez nem ‘ A POSIX szerint, de az IMO-nak ‘ .. ‘ soha nem kellett volna fájlrendszer-koncepciónak lennie, inkább szintaktikusan kell megoldania az útvonalakat, így a/.. mindig a következőt jelentené: .. Így működnek az URL-ek, btw. ‘ az a böngésző, amely ‘ megoldja a ‘ .. ‘ még azelőtt, hogy eléri a szervert. És remekül működik.

A könyvtárak kemény linkjének létrehozása visszavonhatatlan lenne. Tegyük fel, hogy:

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

Keményen összekapcsolom a következővel: /dir2.

Tehát /dir2 most már tartalmazza ezeket a fájlokat és könyvtárakat is.

Mi van, ha meggondolom magam? Nem tudok “csak rmdir /dir2 (mert nem üres)

És ha rekurzívan törlök a /dir2 fájlban. .. törlésre kerül a /dir1 mappából is!

IMHO nagyrészt elegendő ok ennek elkerülésére!

Szerkesztés:

A megjegyzések azt javasolják, hogy távolítsák el a könyvtárat úgy, hogy rm csinálják rajta .De a nem üres könyvtár rm sikertelen, és ennek a viselkedésnek meg kell maradnia, függetlenül attól, hogy a könyvtár merevhivatkozással rendelkezik-e. Tehát “csak rm lehet a leválasztáshoz. Új argumentumra lenne szükség a rm kifejezéshez, csak annyit mondani, hogy” ha a könyvtár inode referencia száma> 1, akkor csak a könyvtár leválasztását “.

Ami viszont megsérti a legkevésbé meglepő másik alapelvet: ez azt jelenti, hogy az imént létrehozott könyvtár merevlemez-link eltávolítása nem azonos az eltávolítással egy normál fájl merevlemez …

Átfogalmazom a mondatom: További fejlesztés nélkül a hardlink létrehozása visszavonhatatlan lenne (mivel egyetlen aktuális parancs sem tudja kezelni az eltávolítást anélkül, hogy következetlen lenne a jelenlegi viselkedéssel)

Ha több fejlesztést engedélyezünk az eset kezelésére, akkor a buktatók száma és az adatvesztés kockázata “nincs elég tudatában a rendszer működésének, egy ilyen fejlesztés azt jelenti, hogy az IMHO elegendő ok-e a címtárakra mutató linkek korlátozására.

Megjegyzések

• Ez nem lehet probléma. Az Ön esetével, amikor hardlinket hozunk létre a dir2-hez, kemény linket kell készítenünk a dir1 összes tartalmára, és így ha átnevezzük vagy töröljük a dir2-t, csak egy további linket törölünk az inode-ra. Ez pedig nem befolyásolhatja a dir1-et és annak tartalmát, mivel legalább egy link (dir1) van az inode-hoz.
• Az érvelése helytelen. Csak leválasztanád, nem rm -rf. És ha a linkek száma eléri a 0 értéket, akkor a rendszer tudná, hogy az összes tartalmat is törölheti.
• Ez ‘ többé-kevésbé az összes rm egyébként is alatta van (leválasztás). Lásd: unix.stackexchange.com/questions/151951/… Ez valójában nem ‘ t, annál inkább, mint a merevhivatkozású fájlokkal. A leválasztás csak eltávolítja a megnevezett hivatkozást és csökkenti a hivatkozások számát. Az a tény, hogy rmdir nem nyert ‘ nem üres könyvtárakat, nem releváns – nem lenne ‘ t tedd ezt dir1 esetén sem. A merevhivatkozások nem ‘ t másolatok az adatokról, ugyanazok a tényleges fájlok, tehát valójában ” törlik a ” a dir2 fájl törli a dir1 könyvtárlistáját. Mindig le kell választania a kapcsolatot.
• Nem lehet ‘ egyszerűen leválasztani, mint egy normál fájl, mert rm egy könyvtárban ne ‘ t válassza le, ha ‘ nem üres. Lásd: Szerkesztés.

Ez jó magyarázat. Ami a “több szülő közül melyiknek kellene .. mutasson?” az egyik megoldás az lenne, ha egy folyamat megtartaná teljes wd elérési útját, akár inodesként, akár stringként. az inodes robusztusabb lenne, mivel a nevek megváltoztathatók. Legalább a régi időkben minden nyitott fájlhoz volt egy belső inode, amelyet minden fájl megnyitásakor növeltek, bezárásakor csökkentek. Amikor eléri a nullát, felszabadul a tárhely, amelyre mutat. Amikor a fájlt már senki nem nyitotta meg, akkor azt (A magon belüli másolatot) elhagyják. Ez érvényben tartaná az elérési utat, ha valamilyen más folyamat egy könyvtárat áthelyezne egy másik könyvtárba, miközben az alkönyvtár egy másik folyamat útvonalán van. Hasonlóan ahhoz, ahogyan egy nyitott fájlt törölhet, de az egyszerűen eltávolításra kerül a könyvtárból, de továbbra is nyitott minden olyan folyamat számára, amelyik nyitva van.

A kemény linkelésű könyvtárakat korábban szabadon engedélyezték a Bell Labs UNIX, legalább V6 és V7, ne tudj Berkeleyről vagy későbbről. Nincs szükség zászlóra. Készíthetnél hurokokat? Igen, ne csináld. Nagyon világos, hogy mit csinálsz, ha hurkot csinálsz. Ha a csomókötést a nyakán kell gyakorolnia, miközben arra vár, hogy a gép ejtőernyősre jusson, ha a másik vége kényelmesen lóg a horogon az ömlesztett fején.

Mi Azt reméltem, hogy ma azt csinálom, hogy a házat összekapcsolom a házzal, hogy elérhető legyen az / home / adminisztrátor, függetlenül attól, hogy az / home-t eltakarták-e egy otthoni automatával, amelynek az adminisztrátor nevű symlink volt. a / lhome / adminisztrátorhoz. Ez lehetővé teszi számomra egy olyan adminisztratív fiók létrehozását, amely az elsődleges otthoni fájlrendszer állapotától függetlenül működik. Ez IS egy kísérlet a linux számára, de azt hiszem, egy időben megtanultam az UCB alapú SunOS számára, hogy az automatikus telepítéseket ascii karakterlánc-szinten végzik. Nehéz felfogni, hogyan lehetne másképp csinálni rétegként bármely tetszőleges FS tetején.

Másutt azt olvastam. és .. már nem fájlok a könyvtárban sem. Biztos vagyok benne, hogy mindezeknek jó okai vannak, és hogy sok minden, amit élvezünk (például az NTFS csatlakoztatása), ilyen dolgok miatt lehetséges, de a UNIX eleganciája a megvalósításban rejlett.Ez az elegancia olyan előnyökkel, mint az általánosság és a alakíthatóság, tette lehetővé, hogy olyan robusztus legyen és kitartson négy évtizede. Amint elveszítjük az elegáns megvalósításokat, végül olyan lesz, mint a Windows (remélem, tévedek!). Valaki létrehozna egy új operációs rendszert, amely elegáns elveken alapul. Gondolkodni való. Talán tévedek, nem ismerem (nyilván) a jelenlegi megvalósítást. csodálatos bár a 30 éves megértés mennyire alkalmazható a Linux számára … legtöbbször!

Hozzászólások

• Úgy gondolom, hogy bár tévedhetek, a . és az .. nem modern hivatkozások a fájlrendszerben, a modern fájlrendszerek esetében. A fájlrendszer-illesztőprogram azonban meghamisítja őket. Ezek a fájlrendszerek akadályozzák a címtárak összekapcsolását. Régi fájlrendszerek esetében ez lehetséges volt (de veszélyes). Ahhoz, hogy megpróbálja, nézze meg a mount --bind cikket, lásd még a mount --make… és esetleg a tárolókat.

Az általam összegyűjtött adatok fő oka az, hogy hasznos a könyvtárnevek megváltoztatása anélkül, hogy elrontanák a futó programokat, amelyek a működő könyvtár más fájlok hivatkozására. Tegyük fel, hogy a Wine-t használta a ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe futtatásához, és a teljes előtagot át akarta helyezni a ~/.wine helyre. Ha valamilyen furcsa oknál fogva a Firefox a drive_c/windows fájlhoz ../../windows hivatkozással, a ~/.newwineprefix törések átnevezésével ért el Az .. megvalósításai, amelyek az anyakönyvtárat inode helyett szöveges karakterláncként követik.

Az egyetlen szülő könyvtár inode-jának egyszerűbbnek kell lennie, mint megpróbálni hogy minden útvonalat nyomon kövessen mind szöveges karakterláncként, mind inode-sorozatként.

A másik ok az, hogy a helytelen viselkedés ng alkalmazás képes lehet hurkok létrehozására. A viselkedő alkalmazásoknak képesnek kell lenniük arra, hogy ellenőrizzék, hogy az áthelyezésre kerülő könyvtár inode megegyezik-e bármelyik beágyazott könyvtár inode-jával, ahová áthelyezik, ugyanúgy, mint egy könyvtárat sem saját maga, hanem ez előfordulhat, hogy a fájlrendszer szintjén nem hajtják végre.

Egy másik ok az lehet, hogy ha hardveres könyvtárakat tudna létrehozni, akkor meg akarja akadályozni, hogy egy olyan könyvtárat összekapcsoljon, amelyet nem lehet módosítani. A find biztonsági szempontokat tartalmaz, mivel más felhasználók által létrehozott fájlok törlésére szolgál ideiglenes könyvtárakból, ami problémákat okozhat, ha a felhasználó valódi könyvtárat vált át egy szimlink számára, miközben find egy másik parancsot hív meg. Ha fontos címtárakat képes összekapcsolni, arra kényszerítené az adminisztrátort, hogy további teszteket adjon a find fájlokhoz, hogy ne befolyásolja őket. (Ok, már te is “nem tudja ezt megtenni a fájloknál, ezért ez az ok érvénytelen.”

Egy másik ok az, hogy a szülőkönyvtár inode tárolása extra redundanciát eredményezhet a fájlrendszer sérülése vagy sérülése esetén. azt akarta, hogy .. felsorolja az összes szülőkönyvtárat, amely erre a linkre mutat, így egy másik, tetszőleges szülő könnyen megtalálható, ha a jelenlegi törlődik, és nem csak az ötletet sérted meg olyan keményen A linkek egyenlőek, meg kell változtatni, hogy a fájlrendszer hogyan tárolja és használja az inodes-eket. Ha a programokkal az utakat sorozatként kezeljük (uniq A könyvtárindexek egyes merevlemezeire) elkerülné ezt, de a fájlrendszer károsodása esetén nem kapja meg a redundanciát.