Noesis
4.2.33 · D5 · HinglishOperating Systems

Question bank — Directory structure — tree, DAG (hard links, symbolic links)

2,111 words10 min read↑ Read in English

4.2.33 · D5 · Coding › Operating Systems › Directory structure — tree, DAG (hard links, symbolic links)

Shuru karne se pehle, do pictures jinpe neeche sab kuch depend karta hai.

Picture 1 — ek name inode nahi hota. Directory entries directories mein rehti hain; actual file ek inode mein rehti hai. Names inodes ki taraf point karte hain; inode ek counter rakhta hai kitne names uski taraf point kar rahe hain.

Figure — Directory structure — tree, DAG (hard links, symbolic links)
Recall Woh ek fact jo saare traps unlock karta hai

Ek directory entry (name) aur ek inode (data + metadata) alag-alag cheezein hain. Ek name ek inode ki taraf point karta hai; inode ek link count store karta hai — ise kahein — jo us inode ki taraf point karne wali directory entries ki sankhya ke barabar hota hai. Ye picture samajh lo aur zyaadatar traps khud hi theek ho jaate hain.

Picture 2 — ek shared file tree ko DAG bana deta hai. Pure tree mein har file ka exactly ek naam hota hai (ek incoming arrow). Jis waqt do names ek inode ki taraf point karein, us node mein do incoming arrows ho jaate hain — ab tree nahi raha, lekin phir bhi acyclic hai: ek DAG.

Figure — Directory structure — tree, DAG (hard links, symbolic links)

Visually farq pehchaanein

Hard link vs symlink ek nazar mein. Ek hard link ek doosra naam hota hai jo seedha inode se wired hota hai ( badhta hai). Ek symlink ek chhota sa alag inode hota hai jiska data ek path ka text hota hai — ye ko touch nahi karta, isliye target ko delete karne par ye dangling reh jaata hai.

Figure — Directory structure — tree, DAG (hard links, symbolic links)

True ya false — justify karein

True ya false: rm file.txt file ka data disk se delete kar deta hai.
Zyaadatar cases mein False. rm unlink call karta hai, jo ek naam remove karta hai aur inode ka link count ghataata hai; data tab free hota hai jab aur koi process isko open nahi rakh rahi.
True ya false: ek hard link file ki ek copy banata hai.
False. Ek hard link usi inode ke liye ek doosra naam hota hai — ek set of data blocks, do darwaze ek hi kamre mein. Kisi bhi naam se edit karne par same bytes change hote hain.
True ya false: ek symbolic link banana target ka link count badhata hai.
False. Ek symlink apna alag inode hota hai jo ek path string store karta hai; target ko pata hi nahi chalta ki symlink exist karta hai, isliye uska link count unchanged rehta hai. Isliye target delete karne par symlink dangling reh jaata hai.
True ya false: hard links wala filesystem phir bhi ek tree hota hai.
False. Ek file jo do naamon se reachable ho, uske do incoming edges hote hain, isliye wo tree nahi raha. Ye ek DAG ban jaata hai — dekho Graphs — Trees vs DAGs — kyunki directory cycles forbidden hain lekin shared children allowed hain.
True ya false: aap do alag filesystems mein ek file ko hard-link kar sakte ho.
False. Ek hard link ek inode number store karta hai, jo sirf ek filesystem ke andar meaningful hota hai. Filesystems cross karne ke liye ek symlink chahiye (jo ek path string store karta hai) — dekho Mount points and Virtual File System (VFS).
True ya false: aap kisi directory ko symlink kar sakte ho.
True. Ek symlink sirf text rakhta hai, isliye ye ek directory, file, ya non-existent path ki taraf point kar sakta hai — hard-link accounting ke liye koi cycle danger nahi, halaanki kernel chain depth ko cap karta hai.
True ya false: har directory, chahe "pure tree" mein bhi, aisi entries rakhti hai jo directory graph ko cyclic banati hain.
True. Har directory . (khud) aur .. (apna parent) rakhti hai, isliye directory graph technically cycles rakhta hai. Yahi wajah hai ki kernel — users nahi — inhe manage karta hai aur isliye user directory hard links banned hain.
True ya false: rm a.txt karne ke baad ek aisi file par jiska hard link b.txt bhi hai, cat b.txt phir bhi kaam karta hai.
True. rm a.txt sirf ko 2 se 1 karta hai; inode aur uska data bachta hai kyunki b.txt abhi bhi unhe reference kar raha hai.
True ya false: ek symlink aur uska target hamesha same inode number share karte hain.
False. Ek symlink ka apna khud ka inode hota hai (type l); target ka alag inode hota hai. Ye hard link se poora farq hai, jo target ka inode share karta hai.
True ya false: ek symlink par stat aur uske target par stat same metadata return karte hain.
False. lstat symlink ka apna metadata report karta hai (chhota sa size = path string ki length, type l); target follow karne par alag size, type, aur inode milta hai. Dekho Unix system calls — link, unlink, symlink, stat.

Error dhundho

Error dhundho: "Ek hard link ek path ki taraf point karta hai, isliye agar main target rename kar dun toh link toot jaata hai."
Ek hard link inode ki taraf point karta hai, path ki taraf nahi — original naam rename karne ya delete karne se data touch nahi hota. Symlink hi path store karta hai aur rename par toot jaata hai.
Error dhundho: "Link count batata hai kitne symlinks ek file ki taraf point karte hain."
Link count hard links (inode ki taraf point karne wale directory entries) count karta hai, symlinks nahi. Symlinks ke liye invisible hain; isliye wo dangle kar sakte hain.
Error dhundho: "File ko zinda rakhne ke liye, uski ek symlink rakho."
Ek symlink mein koi reference hold nahi karta, isliye ye kuch bhi zinda nahi rakh sakta. Survival guarantee ke liye ek hard link chahiye — dekho Reference Counting and Garbage Collection.
Error dhundho: "Jab link count 0 ho jaata hai toh data turant free ho jaata hai, koi exception nahi."
Sirf tab jab koi process file open nahi rakh rahi ho. Ek open file descriptor bhi ek reference hai; blocks tab free hote hain jab aur open-count . Ye classic "ek file delete karo jab ek process abhi bhi usmein likh rahi ho" case hai.
Error dhundho: "ls -l dikhata hai s.txt -> a.txt, toh s.txt sirf a.txt ke liye ek alias inode hai."
-> aur l type char reveal karta hai ki ye ek symlink hai: ek alag inode jiska data text a.txt hai. Same-inode-ka-alias ek hard link hota hai aur koi arrow aur koi l nahi dikhata.
Error dhundho: "Kyunki ye ek DAG hai, main hard links se directories ka ek cycle bana sakta hun."
Ek DAG mein koi cycles nahi hote by definition, aur kernel isliye user directory hard links forbid karta hai taaki cycles prevent ho sakein — warna traversal (find, du) kabhi khatam hi nahi hoti.

Why questions

OS kisi file ka naam uske inode se alag kyun rakhta hai, file ke andar naam store karne ki jagah?
Taaki bahut saare naam ek inode par map kar sakein (hard links) aur taaki directories independent lookup tables ho sakein. Agar naam data mein rehta, toh har file ka sirf ek naam ho sakta tha.
Filesystem ek DAG kyun hai, general graph nahi?
Directory cycles forbidden hain taaki traversal khatam ho aur reference counting meaningful rahe (ek cycle "reachable ⇔ " ko false bana deta). Acyclic + shared children = DAG.
Ek symlink target ka link count kyun nahi badha sakta jabki wo uski "taraf point" karta hai?
Kyunki symlink sirf text store karta hai; target inode creation ke time par consult nahi hota aur uske paas koi back-pointer nahi hota. Pointing lazily access ke time par Path Resolution and the namei() routine ke zariye resolve hoti hai.
Ek hard link delete karne par data kabhi kyun nahi jaata lekin symlink ka target delete karne par jaata hai?
Har hard link ek counted reference hai, isliye ek hatane par sirf link count ek se kam hota hai; baaki naam rakhte hain. Ek symlink uncounted text hai, isliye real naam hatane par 0 ho jaata hai aur symlink ab kuch nahi resolve karta.
Kernel symlink chain depth kyun cap karta hai (typically lagbhag 40 hops)?
Symlinks doosre symlinks ki taraf point kar sakte hain, aur ek symlink apne resolution path mein (indirectly) waapis khud ki taraf bhi point kar sakta hai, jisse ek infinite loop ban jaata hai. Kyunki acyclicity guarantee sirf hard links par cover karti hai, depth cap symlinks ke liye safety net hai. Jab cap exceed ho jaati hai toh kernel error ELOOP return karta hai — ek Unix error code (errno.h se) jiska literal matlab hai "too many levels of symbolic links".
Hard links ek filesystem ke andar kyun rehne chahiye jabki symlinks cross kar sakte hain?
Hard links ek inode number store karte hain, jo sirf apne filesystem ke andar valid hota hai; symlinks ek path string store karte hain, jo resolver / se mount points ke through re-walk karta hai, isliye ye kahin bhi land kar sakta hai.

Edge cases

ln -s a.txt s.txt (symlink) karne par link count ka kya hota hai?
a.txt ka link count unchanged rehta hai (jaise 1). Sirf s.txt ka brand-new inode create hota hai; symlinks kabhi target ka count touch nahi karte.
"Dangling" symlink kya hota hai aur kaise banta hai?
Ek symlink jiska stored path ab resolve nahi hota — target delete ya rename karne se banta hai, ya aisi path par symlink banana jo kabhi exist hi nahi karta tha. Iske cat par "No such file or directory" milta hai.
Agar ek file ka link count 2 hai aur ek naam rm kar diya jaaye jabki ek process ne use open rakha hai, toh state kya hai?
1 ho jaata hai aur bacha hua naam aur open descriptor dono data ko poori tarah zinda rakhte hain; kuch bhi free nahi hota. (Yahan tak ki par ek open fd ke saath, data close hone tak rehta hai.)
Ek brand-new empty directory ka link count kitna hota hai, aur kyun?
2 hota hai: ek entry parent mein uske naam ke liye, aur uska apna . entry khud ki taraf point karta hua. Baad mein jo bhi subdirectory milti hai wo 1 add karti hai (us child ke .. ke zariye).
Kya ek hard link aur jis file se wo linked hai uske alag permissions ya timestamps ho sakte hain?
Nahi. Permissions, timestamps, aur saari metadata shared inode mein rehti hain, isliye har hard link identical metadata dekhta hai. Ek symlink, apna inode rakhne ki wajah se, alag ho sakta hai.
Agar aap kisi symlink ko cp karein, toh kya link ki copy milti hai ya target ki?
Flags par depend karta hai: ek plain cp link follow karta hai aur target ka data copy karta hai; cp -P (ya cp -a) symlink khud (path-string file) copy karta hai. Ye ek frequent silent trap hai.

Connections

  • Inodes and File Metadata
  • Path Resolution and the namei() routine
  • Reference Counting and Garbage Collection
  • Graphs — Trees vs DAGs
  • Unix system calls — link, unlink, symlink, stat
  • Mount points and Virtual File System (VFS)