jakkoliv nechci zpochybnovat genialitu hardlinku obecne a genialitu toho napadu ze zalohovanim zvlast ;) zajimalo by me, k cemu opravdovi unixovi guruove jeste hardlinky normalne pouzivaji. Me se totiz hardlinky zpocatku libily, dokonce hodne moc, a to zejmena diky tomu, ze jsem si precetl, jak jsou vlastne implementovane.
Postupem casu jsem ale zacal pouzivat spis symlinky, jak na adresare, tak na jednotlive soubory, pricemz vlastnost "broken link" se mi postupem casu zacala spis libit. Castym duvodem smazani souboru (resp. odsunuti na jinou partition) je totiz nedostatek mista na disku. V pripade hardlinku by nalezeni vsech kopii nazvu souboru trvalo neumerne dlouho. "Broken symlink" ma v tomhle smeru i tu vyhodu, ze muze zustat kde je, nefunguje, ale po vraceni souboru na puvodni misto zase fungovat zacne. To je nekdy docela pohodlne...
Hardlinky na adresare by me tereticky prisly velice zajimave - podle me hlavni duvod proc neexistuji je ten, ze by souborovy strom mohl snadno prestat byt acyklicky, coz by pro radu programu (find, cokoliv -R) mohlo mit katastrofalni nasledky. Sorry jestli to clanek pise, jen jsem ho preletl ;-)
Dalsi problem je prikaz s hardlinky je prikaz du. (Prikaz df naproti tomu bude fungovat normalne)
Pokud vim, v zadne dnesni distribuci hardlinky nejsou. Zajimalo by me, k cemu dalsimu je kdo doporucuje pouzit - krome te zajimave, i kdyz trochu krkolomne moznosti vytvareni "kompletnich zaloznich kopii" ? V zasade poslednich nekolik let, kdyz jsem potreboval mit "jeden soubor na dvou mistech", tak jsem to proste zasadne resil symlinkem. Jak je to vubec s hardlinkem a uzivatelskymi pravy ? Lze pomoci nej vytvorit soubor se zcela odlisnymi pravy ? moment... test... nejde. Samozrejme - pristupova prava jsou primo vlastnost inodes... pritom zrovna moznost vytvareni kopie tehoz souboru se zcela odlisnymi pravy by unixovym systemum hodne prospela, protoze by to byla nahrazka za nektere chybejici groupwarove vlastnosti :-(
Pouzitie hard linkov v tomto pripade ma tu krasnu vlastnost, ze na rozne prikazy gzip, gunzip, zcat existuje len jedina binarka a pri jej spusteni sa na zaklade mena [v perle je to $0, ci to je v C argv[0] uz teraz presne nepamatam] vykona patricna akcia. Napriklad v sendmail instalaciach je "mailq" tiez iba hard linka na "sendmail". Takze tak ...
Symlinky dnes jasne vedou, zvlaste diky tomu, ze vice odpovidaji tomu, co si lide predstavuji pod "odkazem".
S hardlinky na adresare mate pravdu a ackoli UNIXovy filesystem obecne by je mel umet vytvorit, ext2 a ext3 vam je vytvorit nepovoli.
Jinak dnesni distribuce hardlinky samozrejme obsahuji, napr. Mandrake 9.0 nekolik set pri defaultni instalaci, zvlaste v souborech s casovymi zonami, jako aliasy pro prikazy atd.
Hardlinky se občas používají, když se jeden program chová odlišně, podle jména, kterým se volá. Teď mě zrovna napadá jen jeden příklad: na FreeBSD se už nějakou dobu používá jako pager less místo more. Respektive less a more jsou odkazy na stejný inode se stejným programem.
Povedal by som. ze je to hlavne historicka zalezitost. Boli casy ked sa pocital kazdy byte. Ja nie som taky stary, ale pamatam si na disky o velkosti 20MB ( ano mega-bajtov ). Nuz a v tom case uz UNIX slapal ako hodinky.
Prave na takychto malych diskoch ma pouzitie hardlinku velky vyznam. Najcastejsie sa pritom pouzival pre programy ktore na nazvu suboru vykonavali odlisnu cinnost. Napr. gzip, gunzip a gzcat su uplne identicke programy, obdobne to plati pre compress, uncompress a zcat. Urcite by sa dali najst aj dalsie. Dnes sa to riesi symbolickou linkou, to ale znamena obsadenie noveho inode, teda minimalne XXX-bajtov ( XXX zavisi od filesystemu ).
Len tak mimochodom hardlinky sa stale pouzivaju. Toto som nasiel na RedHat 7.2 ( moze sice byt ze to tam doplnil nas systemak )
ls -i /bin/gzip /bin/gunzip
304651 /bin/gunzip 304651 /bin/gzip
Ja je pouzil napriklad, kdyz jsme vydavali CD s daty,
ktera bylo mozne tridit do adresaru mnoha zpusoby.
Kdybych delal pokazde kopie, neveslo by se to na CD
(1 kopie dat byla tak asi tech 600Mb). CD se melo palit jak s Joliet tak s RR rozsirenimi. Symbolicke linky by tak nefungovaly ve Win. Pouzili jsme tedy
pevne linky a cdrecord je zachoval v tom smyslu, ze
opravdu palil jen jednu kopii dat, kazdy soubor slo
ale najit hned v nekolika adresarich.
Todle je jen prispevek do diskuse, ne pevne tvrzeni ;-)
Mam za to, ze by melo jit hardlinky pouzit na regulaci pristupovych prav: muzu mit adresar, do nejz ma pravo jen nejaky uzivatel a v nem jeden link (s pravy pro grupu/vsechny), totez pro jineho uzivatele v jinem adresari... takto by mohlo jit klasicke omezeni na tri skupiny pristupu k souboru.
(priklad: mam soubor, ktery maji mit pravo editovat dva lide a cist jen nejaka dalsi skupina)
Opravi me nekdo? A existuje zpusob, jak pristupovat k souboru, jehoz inode znam, mam na nej prava, ale lezi v adresari me nedostupnem, nebo by to z principu jit nemelo?
> Dalsi problem je prikaz s hardlinky je prikaz du.
To tedy nahodou neni :-)
du zobrazuje pouze skutecne obsazene misto, coz si muzes vyzkouset.
Dalsi skvela vec du a unixovych filesystemu je, ze mohou obsahovat ridke soubory, tzn. kdyz si dam ls, tak ten soubor je velky 600MB, ale kdyz dam du, tak vidim, ze zabira par mega, protoze se do nekterych mist nic nezapsalo.
Velmi užitečné mohou být hardlinky při chrootování.
Nemusím totiž vytvářet kopie celého prostředí nutného pro běh chrootovaného serveru, obvykle stačí většinu z toho nalinkovat. Musím ale samozřejmě použít hardlinky, protože těch se chroot netýká -- právě proto, že ukazují na inode a nikoli na místo v adresářové sktruktuře. Symlink by se převedl na jméno v chrootovaném filesystému, čímž bychom se nikam nedostali.