4.2.33
Ek filesystem ko ek sawaal fast answer karna hota hai: "ek naam diya, toh data kahan hai?"
Directory bas ek lookup table hai jo human-readable names ko low-level file identifiers (inodes on Unix) se map karti hai.
Agar har file ka exactly ek naam ho aur directories kabhi bhi children share na karein, toh namespace ek tree hai.
Jaise hi hum ek single file ko multiple names/paths se reachable hone dete hain, tree ek Directed Acyclic Graph (DAG) ban jaata hai.
WHY ek DAG aur general graph kyun nahi? Hum directories mein cycles forbid karte hain taaki traversal (find, du, recursive delete) terminate ho aur reference counting sane rahe.
Definition Inode vs. name
Inode woh on-disk structure hai jo file ki metadata + data block pointers (size, permissions, timestamps, link count) rakhta hai — lekin NOT the name.Ek directory khud ek file hai jiske contents (name, inode_number) pairs ki ek list hoti hai jise directory entries (dentry) kehte hain.
Name ko inode se alag karna woh ek idea hai jo hard links, links, aur DAG ko possible banata hai.
Intuition Name ko data se alag kyun rakha?Agar naam file ke data ke andar rehta, toh ek file ka sirf ek naam ho sakta tha. Directories mein names rakh ke aur data ko inode number ke peeche rakh ke, kai naam ek inode ki taraf point kar sakte hain — jaise phonebook ki kai entries same phone number list karti hain.
Definition Tree namespaceEk tree ek connected acyclic graph hai jahan har node (root / ko chhod ke) ka exactly ek parent hota hai. Har file/directory ek unique path se reachable hoti hai.
WHY tree convenient hai: unique path ⇒ unique name ⇒ deletion trivial hai (ek entry, inode free karo). HOW hum ise walk karte hain: / se start karo, path ko / par split karo, current directory mein har component ka inode lookup karo, repeat karo.
Ek "pure tree" mein bhi secretly har directory mein do special entries hoti hain:
. → directory ka apna inode.. → parent ka inode
Yeh directory graph ko directories ke liye technically cyclic banate hain, aur exactly yahi reason hai kyun hum user-created directory hard links ban karte hain (aage aur baat karenge).
Ek hard link same inode ki taraf point karne wali ek aur directory entry hai. Koi "original" aur "copy" nahi hoti — sab names ek inode ke equal first-class references hain.
Worked example Hard link in action$ echo hi > a.txt # inode 42, link count = 1 $ ln a.txt b.txt # b.txt → inode 42, link count = 2 $ ls -li 42 -rw-r--r-- 2 ... a.txt 42 -rw-r--r-- 2 ... b.txt # SAME inode 42, count "2" $ rm a.txt # count -> 1, data still alive $ cat b.txt hi # still readable! Yeh step kyun? rm a.txt sirf naam remove karta hai aur count decrement karta hai; data survive karta hai kyunki b.txt abhi bhi inode 42 ko reference karta hai.
Intuition Hard links kyun ise DAG banate hain, tree nahiDo alag paths (a.txt, b.txt) ab same node tak lead karti hain. Ek node jisme >1 incoming edge ho ⇒ tree nahi. Lekin kyunki hum directory-to-ancestor links forbid karte hain, no cycles ⇒ ek DAG .
Hard links par constraints (aur WHY):
Cannot cross filesystems — inode numbers sirf ek filesystem ke andar meaningful hote hain.Cannot hard-link directories (users ke liye) — cycles create hoti, traversal tod deta aur "reachability" ke liye link count undefined ho jaata. (Kernel khud ./.. carefully use karta hai.)
Ek symbolic link (symlink) ek special file hai jiska data ek text path string hai . Ise resolve karne ka matlab hai: string padho, phir us string se path lookup re-start karo.
Intuition Hard vs soft — core difference
Hard link = inode ka ek doosra sachcha naam (inode ki taraf point karta hai).
Symlink = ek signpost jo kehta hai "wahan jaao dekho" (path ki taraf point karta hai, text ke zariye).
Symlink ke target ko delete karo aur aapko ek dangling/broken link milta hai — signpost kuch nahi point karta. Ek hard link delete karo aur data jeeta rehta hai.
Worked example Symlink behaviour$ echo hi > a.txt # inode 42 $ ln -s a.txt s.txt # s.txt is inode 99, data = "a.txt" $ ls -li 42 -rw-r--r-- 1 ... a.txt 99 lrwxrwxrwx 1 ... s.txt - > a.txt # NEW inode, type 'l' $ rm a.txt $ cat s.txt cat: s.txt: No such file or directory # dangling! Yeh step kyun? s.txt ne sirf text "a.txt" store kiya tha; jab woh naam chala gaya, resolution fail ho gayi. Note karo ki a.txt ka link count 1 raha — symlink creation target ka count bump nahi karti.
Worked example Symlinks woh kar sakte hain jo hard links nahi kar sakte$ ln -s /mnt/usb/movie.mp4 ~/film # cross-filesystem: fine! $ ln -s /var/log mylog # link to a DIRECTORY: fine! Yeh step kyun? Ek symlink sirf ek path string store karta hai, isliye isme koi inode-number / same-filesystem restriction nahi hai aur traversal ke liye koi cycle danger nahi hai (kernel symlink chain depth limit karta hai, e.g. ~40 hops ke baad ELOOP).
Property
Hard link
Symbolic link
Points to
inode path string
Apna inode?
Nahi (target ka share karta hai)
Haan (alag inode)
Target link count bump karta hai?
Haan Nahi
Target deletion ke baad survive karta hai?
Haan (count 0 tak)Nahi → dangling
Cross-filesystem?
Nahi
Haan
Directory ko link kar sakta hai?
Nahi (users)
Haan
ls -l type char- (normal)==l==
Common mistake Steel-manned misconceptionsA) "rm file delete karta hai."
Kyun sahi lagta hai: roz ki life mein ek naam = ek file. Sachchi baat: rm unlink call karta hai, jo ek naam remove karta hai aur link count decrement karta hai. Data sirf count 0 par marta hai (aur koi open fd nahi). Fix: "unlink" socho, "delete" nahi.
B) "Ek symlink file ko hard link ki tarah alive rakhta hai."
Kyun sahi lagta hai: dono file ki taraf "point" karte hain. Sachchi baat: ek symlink text store karta hai, link count touch nahi karta, isliye target delete karne par woh toot jaata hai. Fix: hard link = reference (counted); symlink = pointer (uncounted).
C) "Hard-linked file ko copy karna ek ko copy karta hai aur doosra chodh deta hai."
Kyun sahi lagta hai: yeh do files jaisi dikhti hain. Sachchi baat: kisi bhi naam se in-place editing same data change karti hai. Fix: ek inode, same room mein do darwaze.
D) "Filesystem ek tree hai."
Kyun sahi lagta hai: file explorer mein yeh tree jaisi dikhti hai. Sachchi baat: hard links ke saath yeh DAG hai; symlinks ke saath aap traversal cycles bhi create kar sakte hain (isliye kernels symlink depth cap karte hain). Fix: tree default hai, DAG reality hai.
Recall Feynman: 12-saal ke bachche ko samjhaoSocho ek bada toy box (data) jisme ek label number painted hai. Ek hard link deewar par ek sticker hai jo kehta hai "toy box #42." Aap alag-alag rooms mein bahut saare stickers laga sakte ho sab "#42" kehte hue — woh sab same box kholte hain. Box ek chhota counter rakhta hai kitne stickers uski taraf point karte hain; box sirf tab phenka jaata hai jab aakhri sticker hata diya jaata hai. Ek symbolic link alag hai: yeh ek sticky note hai jo bas kehti hai "kitchen mein jao aur teddy wala box dhundho." Agar koi kitchen wale box ka naam badal de, tumhari sticky note ab kuch bhi point nahi karti — ek dead note. Kyunki kai stickers ek box ko point kar sakte hain, naam ka map ek simple family tree nahi raha; yeh ek aisa web hai jo kabhi apne aap par loop nahi karta — ek DAG .
"HARD HEART (inode) ki taraf point karta hai; SOFT SPOT (path) ki taraf point karta hai."
Aur: "Hard counts, Soft doesn't." (Hard link link count increment karta hai; symlink nahi karta.)
Inodes and File Metadata File System Implementation — Block Allocation Path Resolution and the namei() routine Mount points and Virtual File System (VFS) Graphs — Trees vs DAGs Reference Counting and Garbage Collection Unix system calls — link, unlink, symlink, stat
Ek directory entry (dentry) kya map karti hai? Ek human-readable naam ko ek inode number se.
File ka naam kahan store hota hai — inode mein ya directory mein? Directory mein (inode metadata + data pointers rakhta hai, naam nahi).
Hard links ke saath filesystem DAG kyun hai tree ki jagah? Multiple paths/names same inode tak pahunch sakti hain (in-degree >1), lekin directory cycles forbidden hain, isliye yeh acyclic hai.
Hard link kya hota hai? Ek additional directory entry jo same inode ko point karti hai; ek sachcha co-equal naam.
Inode link count kya hai aur data blocks kab freed hote hain? Inode ko reference karne wali dentries ki sankhya; blocks sirf tab freed hote hain jab link count = 0 AND koi process usse open na rakhe.
Kya symlink create karna target ka link count change karta hai? Nahi — symlink ka apna inode hota hai aur sirf target ka path text ke roop mein store karta hai.
Dangling symlink kya hota hai? Ek symlink jiska target path ab exist nahi karta, isliye resolution fail ho jaati hai.
Do cheezein jo symlink kar sakta hai jo hard link nahi kar sakta? Filesystems cross kar sakta hai, aur directory ko link kar sakta hai.
Users hard-link directories kyun nahi kar sakte? Yeh cycles create kar sakta hai, traversal aur reference counting tod ke.
rm actually kya call karta hai, aur woh kya karta hai?unlink(); ek naam remove karta hai aur inode link count decrement karta hai.
Symlink ke liye ls -l ka pehla character? 'l'.
Hard vs soft links ke liye mnemonic? Hard HEART (inode) ki taraf point karta hai; Soft SPOT (path) ki taraf point karta hai. Hard counts, Soft doesn't.
adds dentry to same inode
Directory as lookup table
Directory entry name to inode
