A UNIX operációs rendszer fájlrendszere hierarchikus, a rendszerben egyetlen gyökér-directory van, és annak tetszoleges mélységben tetszoleges számú aldirectoryja lehet, azoknak az aldirectoryjainak szintén tetszolegesen sok aldirectoryjuk lehet, stb. A UNIX a fájlt egyszeruen egy byte-folyamnak tekinti. A UNIX rendszerben létezik a munka-directory koncepciója (minden folyamatnak van egy saját munka-directoryja). A UNIX abban lényegesen különbözik az MS-DOS-tól, hogy csak egy gyökér-directoryja van, és a mágneslemezeken levo külön fájlrendszerek (a lemezen kialakított directory-strukturák) beilleszthetok (mountolhatók) a gyökérdirectory- rendszerbe. Erre nézzünk egy példát -- a UNIX gyökér-fájlrendszere tartalmaz több directoryt:
Most tegyük fel, hogy van egy fájlrendszerünk egy floppy-diszken, amely a következo dolgokat tartalmazza:
A felhasználó kérheti a UNIX rendszert, hogy illessze be a floppy-diszken levo fájlrendszert a gyökér-fájlrendszer valamelyik üres directoryjába. Most nézzük, hogy mi lesz akkor, ha a fenti gyökér-fájlrendszer /usr/csb directoryjába beillesztjük a fent elképzelt floppy-diszken levo fájlrendszert. Ezután a floppyn levo fájlokat a következo neveken érhetjük el:
Természetesen ha ezekre a fájlokra máshol lenne szükség (pl. a /tmp directoryban, akkor oda is be lehetne oket illeszteni - mountolni). Ez az alapja a UNIX ún. készülékfüggetlenségének. A fájlokra való hivatkozáskor nem kell tudni azt, hogy az adott fájl milyen fizikai periférián van. Ehelyett elég a fájlnak a fájlrendszer-hierarchiabeli nevét megadni.
A UNIX-ban minden egyes fáhlhoz tartoznak ún. védelmi bitek (ezeket rwx biteknek is nevezik). A fájlokat ezekkel lehet védeni a jogosulatlan hozzáférés ellen. Mint már szó volt róla, minden felhasználónak van egy saját uid-je, gid-je. Lényegében ez a UNIX fájlvédelmének az alapja. Minden egyes fájlhoz tárolva van az ot létrehozó felhasználó uid-je és gid-je, illetve a fent említett rwx- bitek (összesen 9 bit). Az rwx-bol az "r" betu a fájl elolvasási jogát jelenti, a "w" betu a fájl felülírási (módosítási) jogát jelöli, és a végrehajtható programok esetén az "x" bit a végrehajtási jogot jelöli. Az rwx-bitekkel meg lehet adni, hogy a fenti 3 jog közül a fájlt létrehozó felhasználónak milyen jogai vannak a fájlon; a fájlt létrehozó felhasználó csoporttársainak milyen jogai vannak; és végül meg lehet adni, hogy azoknak az "egyéb" felhasználóknak, akik a fenti két halmaz egyikébe sincsenek benn mik legyenek a jogai. (A védelmi bitek sorrendje ugyanez; eloször a tulajdonos, majd a csoporttársak, végül pedig az egyéb felhasználók jogait kell megadni.) Ha egy fájl védelmi bitjei r-xr-x--x alakúak, akkor a tulajdonos a fájlt elolvashatja, végrehajthatja (de nem módosíthatja); a tulajdonos csoporttársainak ugyanez a joguk; az egyéb felhasználóknak pedig csak végrehajtási joguk van. A fájlhoz tartozó védelmi biteket csak a fájl tulajdonosa vagy a root (superuser) változtathatja meg.
Ezen kívül néhány végrehajtható fájlnál érdemes használni a UNIX egy más speciális lehetoségét: a sticky bitet. Ha ez a bit be van állítva egy végrehajtható fájlon, és a fájlban tárolt programot végrehajtják, akkor a program befejezodése után a kódszegmense (ha az nem változott meg) megmarad a winchester virtuális memória területén - így egy következo végrehajtás valószínuleg gyorsabban fog elkezdodni, mivel a kódszegmens újbóli betöltése megspórolható. (Egy speciális védelmi bitrol - a setuid bitrol késobb lesz szó.)
A UNIX rendszerben egy másik nagyon jó ötlet az ún. speciális fájlok koncepciója. Ilyen módon az egyes hardware perifériákat a fájlrendszerbeli nevükön érhetjük el. Az ötlet azon alapszik, hogy például egy 360 KByte-os (mondjuk IBM PC/XT formátumú) floppy-diszket tekinthetünk úgy, mint egy 360 KByte-os fájlt. Ha a lemezen a blokkméret 512 byte, akkor az ilyen fájl elso karaktere a diszk 0-adik blokkjában az elso byte; a fájl 512-edik karaktere a diszk 0-adik blokkjában az utolsó (512-edik) byte, például az 1025-ödik byte pedig a diszk második blokkjának az elso karaktere ... Vannak blokk-speciális fájlok, és karakter-speciális fájlok. A blokk-speciális fájlok abban különböznek a karakter-speciális fájloktól, hogy a blokk-speciális fájloknak néhány "gyakrabban használt" blokkja a cache memóriában marad a gyorsabb elérés érdekében, míg a karakter- speciális fájloknál erre nincs lehetoség.
A UNIX fájlrendszrében a /dev directory tartalmazza az ilyen speciális fájlokat. Például a legtöbb rendszerben a /dev/fd0 néven a 0-ás lemezegységet érhetjük el (PC-ken ez az MS-DOS alatt az A: jelu lemezegység).
A UNIX másik érdekes lehetosége a pipe ( csovonal). Ez a párhuzamos folyamatok közötti kommunikáció (IPC) egyik eszköze. Ezt tényleg úgy tekinthetjük, mint két folyamat közti csovonalat: az egyik folyamat írhat ebbe a csovonalba valamilyen adatokat, a másik folyamat pedig kiolvashatja a beírt adatokat a pipe-ból. (A pipe csak egy half-duplex (egyirányú) kapcsolatot biztosít, vagyis ha mindkét résztvevo folyamat akar a másiknak adatokat küldeni, akkor a kétirányú adatátvitelhez két ilyen pipe-ra van szükség.) A pipe-ra írni és arról olvasni is a UNIX fájlmuveleteivel lehet. Sot lehetoség van arra is, hogy pipeokat névvel lássunk el (a pipeok nevei ekkor fájlnevek lesznek, amin keresztül bármelyik folyamat tud a pipera írni - esetleg arról olvasni, ehhez csak a pipehoz tartozó fájl nevét kell ismernie).
Érdekes még, hogy a hálózati kapcsolatok is lényegében fájldeszkriptorokon keresztül érhetok el, de errol majd késobb lesz szó.
A UNIX egy többfelhasználós operációs rendszer, így egy fájlt egyszerre több felhasználó is változtathat. Ez gyakran problémák forrása is lehet. Nézzük a következo helyzetet: egy bank számítógépén UNIX rendszer fut, a számítógéphez több képernyo van kapcsolva (minden egyes pénztáros asztalán van egy-egy terminál). Tegyük fel, hogy két pénztárhoz egyszerre megy oda két ügyfél, és ugyanarra a bankszámlára mindketten 500 forintot akarnak rakni. Ekkor mindkét számítógép kiolvassa a számla aktuális egyenlegét (ez legyen mondjuk 1000 forint), kiszámolja, hogy mennyi lesz az 500 forint berakása után az új egyenleg (1500 forint), és visszaírja azt. Mivel ezek az ügyfelek lehet, hogy nem is tudnak arról, hogy a másik is ugyanarra a számlára rakott be 500 forintot, boldogan mennek hazafelé a bank-igazolással, amelyen új egyenlegként 1500 forint van feltüntetve, nem veszik észre, hogy a gép hibázott. Mivel a gyakorlatban az ilyen eseteket nem szabad elhanyagolni (egy nagyobb bank központi számítógépére több ezer terminált rá lehet kapcsolni), és sok olyan számlaszám van, amelyre sokan fizetnek be pénzt (pl. közhasznú alapítványokra), ezért erre kell valami megoldást találni.
A UNIX az ilyen esetekre nyújtja a fájl- ill. rekord-lefoglalás (fájl and record locking) lehetoségét. Egy folyamat kérheti az operációs rendszert, hogy egy fájlt vagy annak egy részét "foglaljon le" egészen addig, amíg a folyamat el nem végzi rajta a dolgát (mondjuk inkább úgy, hogy a feladatát ...). A lefoglalás ideje alatt más folyamat nem nyúlhat a fájl lefoglalt részéhez; ha mégis hozzá akarna nyúlni, akkor várnia kell addig, amíg a fájlt lefoglaló folyamat "elengedi" a fájlt.
Másik fontos eltérés a UNIX és az MS-DOS fájlrendszere között az, hogy a UNIX fájlrendszerben nem egy közös nagy MS-DOS-ban használt FAT-szeru táblázatban tárolják azt, hogy a fájl a diszk melyik blokkjain helyezkedik el, hanem minden egyes fájlhoz külön tárolják (egy-egy a fájlhoz tartozó ún. i-nodeban) azt, hogy a fájl a diszk melyik részén helyezkedik el. Az i-node tárolja azt is, hogy ki a fájl tulajdonosa (mi volt a tulajdonos uid-je és gid-je akkor amikor a fájlt létrehozta), mekkora a fájl hossza (byteban mérve), mikor hozták létre, mikor módosították utoljára, mik a fájl védelmi bitjei. Minden egyes i-nodenak van egy sorszáma, és a directoryk (lényegében speciális fájlként - amit megnyithatunk és ezeket az információkat kiolvashatjuk belole) a következo információk sorozatát tartalmazzák:
Ez azért hasznos, mert így egy fájlra több directoryból is hivatkozhatunk. Ezzel megoldhatjuk azt, hogy két vagy több felhasználó ugyanazt a fájlt elérje a saját directoryjából. Erre nézzük a következo példát: a /usr/pista directoryban van egy ilyen bejegyzés :
a /usr/mariska directoryban pedig a következo bejegyzés van (a szerkezet a fent bemutatottak szerint értendo):
Itt a test.c illetve a proba.c fájloknak más a neve, de a két fájl (tartalma) egy és ugyanaz. Ha mondjuk a /usr/mariska/proba.c fájl le lesz törölve, akkor a fájl (a benne tárolt adatokkal) a lemezrol nem lesz letörölve, mert még hivatkoznak rá /usr/pista/test.c néven. (Egy ilyen hivatkozást neveznek az i-nodera mutató linknek - nyilván az i-node tartalmaz egy referenciaszámlálót, és a fájl csak akkor lesz ténylegesen törölve, ha e referenciaszámláló értéke nullára csökken.) Eszerint egy fájl a lemezrol csak akkor lesz letörölve, ha rá egyetlen link sem vonatkozik.
Itt érdemes megjegyezni azt is, hogy az i-node tartalmazza azokat az információkat, amely alapján a fájl helye a diszken "feltérképezheto" a következok szerint. Az i-node tartalmaz 13 darab blokk-címet (a UNIX csak blokk-elérésu perifériákon tud fájlrendszert létrehozni) - most a példa könnyebb megértése érdekében feltételezzük, hogy a blokkméret 1 KByte. Ebbol a 13 blokk-címbol 10 darab ún. direkt cím. Azaz azok közül az elso tartalmazza annak a (diszk-)blokknak a címét, amelyen a fájl elso 1024 (1 Kbyte) darab byteja van. A második tartalmazza annak a (diszk-)blokknak a címét, amelyen a fájl következo 1024 byteja van, stb. . A 11-edik blokk-cím egy ún. egyszeres indirekt blokk-cím (single indirect): az a blokk, amelyet ez az egyszeres indirekt blokk-cím megcímez mind direkt címeket tartalmaz. (Ha egy blokk-cím mérete n byte, akkor összesen 1024/n darab direkt cím fér ide.) Vagyis az egyszeres indirekt blokkban tárolt elso cím a fájl 11-edik kilobyteját tartalmazó diszk-blokk címét tartalmazza.
A 13-ból a 12-edik egy ún. kétszeres indirekt blokk-cím (double indirect address): az a blokk, amelyet ez a kétszeres indirekt blokk-cím megcímez mind egyszeres indirekt címeket tartalmaz - ezek szerkezete olyan, mint azt az elobb leírtam.
A 13-adik pedig egy háromszoros indirekt blokk-cím (triple indirect): az ez által megcímzett blokk 1024/n darab kétszeres indirekt blokk- címet tartalmaz. (Ha egy fájl hossza mondjuk 4567 byte, akkor csak az elso 5 direkt cím van kitöltve "értékes" információkkal. A többi helyen mindegy mi van.)