File operations — open, read, write, seek, close: Worked examples

4.2.32 · D3 · Coding › Operating Systems › File operations — open, read, write, seek, close

Yeh page 4.2.32 File operations — open, read, write, seek, close ka exhaustive worked-examples companion hai. Yahan hum sirf baat nahi karte ki open, read, write, lseek, close kaise behave karte hain — balki unhe har possible case se guzarte hain — offset ka har sign, har degenerate input, har limiting value — jab tak koi bhi scenario tumhe surprise na kar sake.

Scenario matrix

In paanch calls se jo bhi situation aa sakti hai woh neeche kisi na kisi cell mein hai. Aane wale examples mein se har ek uss cell ka label liye hoga jise woh cover karta hai, aur milke yeh sab cells cover karte hain.

Cell	Case class	Tricky kyun hai
A	`lseek` positive offset, `SEEK_SET`	absolute jump forward
B	`lseek` negative offset, `SEEK_END`	"N bytes before end" — sign matter karta hai
C	`lseek` offset past EOF + write	ek sparse file (hole) banta hai
D	`lseek` exact boundary par (offset = 0, offset = size)	degenerate/edge position
E	`read` returns `n < count` (short read)	chhoti file / partial data
F	`read` returns `0`	EOF — error nahi hai yeh
G	`read`/`write` returns `-1`	genuine error, `errno` set hai
H	`write` short write → loop	`buf + total` se resume karna zaroori hai
I	`open` degenerate: missing file, no `O_CREAT`	fail hota hai, returns `-1` (ENOENT)
J	Limiting value: fd exhaustion (`ulimit`)	fds leak karte raho jab tak `open` fail na ho
K	Real-world word problem	concurrent append logging
L	Exam twist	`O_APPEND` + `SEEK_CUR` ke saath offset arithmetic

Picture banana: offset number line

Examples se pehle, ek image. Offset ek single non-negative integer hai — file ke start se bytes mein measure kiya gaya ek bookmark position. lseek jo bhi karta hai woh iss ek number par arithmetic hai.

Figure — File operations — open, read, write, seek, close

Worked examples

Example 1 — absolute forward jump (cell A, D)

Worked example Statement

Ek 20-byte file. Tum lseek(fd, 5, SEEK_SET) call karte ho, phir read(fd, buf, 3). buf mein kaunse bytes aate hain, aur baad mein offset kya hoga?

Forecast: aage padhne se pehle byte indices guess karo.

Naya offset compute karo. SEEK_SET ka origin position 0 hai, isliye newpos = offset = 5. Yeh step kyun? SEEK_SET current bookmark ko bilkul ignore karta hai — yeh ek absolute jump hai. Bookmark ab byte index 5 se pehle baitha hai.
3 bytes read karo. read offsets 5, 6, 7 par bytes ko buf mein copy karta hai, phir offset ko 3 se aage badhata hai. Yeh step kyun? read hamesha current offset se shuru hota hai aur use exactly utne bytes se aage badhata hai jitne woh return karta hai.
Naya offset = 5 + 3 = 8.

Verify: humne 3 bytes read kiye (indices 5,6,7), last read index 5+3-1 = 7 < 20 hai, toh koi EOF nahi. Offset 8 clearly [0, 20] ke andar hai. ✔

Example 2 — end se negative offset (cell B)

SEEK_END formula apply karo. newpos = size + offset = 20 + (-4) = 16. Yeh step kyun? SEEK_END position = size (20) se start karta hai. Ek negative offset wahan se peeche chalta hai — yeh "last N bytes" ke liye the idiom hai.

4 bytes read karo offsets 16, 17, 18, 19 par → final chaar bytes. Offset 16 + 4 = 20 = size par khatam hota hai (bookmark ab EOF par hai). Yeh step kyun? size - 4 last chaar indices mein se pehla hai; size tak read karne se exactly tail consume ho jaati hai.

-25 wala degenerate case: newpos = 20 + (-25) = -5 < 0. Negative result illegal hai — lseek returns -1 aur errno = EINVAL set karta hai. Kuch bhi move nahi hota. Yeh step kyun? Cell B ko invalid sub-case bhi cover karna chahiye: file ke start se pehle seek nahi kar sakte.

Verify: last valid index size-1 = 19 hai; hamare chaar indices 19 par khatam hote hain. ✔ -25 ke liye: 20-25 = -5, aur bookmark negative nahi ho sakta, toh failure sahi hai. ✔

Example 3 — EOF se aage seek karne se hole banta hai (cell C)

Size-0 file par 100 tak seek karo. newpos = 100. Yeh allowed hai — EOF se aage seek karna legal hai; isse file abhi grow nahi hoti. Yeh step kyun? lseek sirf offset integer ko touch karta hai (galti-killer: yeh koi data move nahi karta), isliye yeh happily current end ke baad land kar jaata hai.

Offset 100 par 1 byte write karo. Ab file kam se kam 100 + 1 = 101 bytes ki honi chahiye. Bytes 0–99 kabhi write hi nahi kiye gaye. Yeh step kyun? Old size (0) aur write position (100) ke beech ka gap ek hole ban jaata hai.

Hole zeros ki tarah read back hota hai. Bytes 0–99 par koi bhi read \texttt{0x00} return karta hai. Disk par hole koi real blocks occupy nahi karta — yahi ek sparse file hai. Yeh step kyun? Filesystem record karta hai "yeh blocks implicitly zero hain" rather than 100 literal zero bytes store karne ke.

Verify: logical size = \max(\text{old size}, \text{write end}) = \max(0, 101) = 101. Byte 100 mein 'X' hai; bytes 0–99 0 ki tarah read hote hain. ✔

Example 4 — chhoti file par short read (cell E, F)

Worked example Statement

Ek file mein exactly 7 bytes hain. Tum read(fd, buf, 100) ko do baar loop karte ho. Har call kya return karti hai?

Forecast: pehla return? doosra return?

Pehla read. Offset 0, 100 maango. Sirf 7 bytes hain → read returns n = 7 (ek short read, cell E). Offset 7 tak advance ho jaata hai. Yeh step kyun? read up to count return karta hai; jab kam bytes bachte hain, n < count hota hai. Yeh normal hai, error nahi.
Doosra read. Offset ab 7 = size hai. Kuch nahi bacha → read returns 0 (cell F, EOF). Offset 7 par hi rehta hai. Yeh step kyun? 0 ka return sirf end-of-file ka signal hai. Errors -1 hote.
Sahi copy idiom. write(1, buf, n) mein n = 7 use karo, 100 kabhi nahi — buf ke bytes 7–99 uninitialised garbage hain. Yeh step kyun? Buffer ke sirf pehle n bytes valid hain.

Verify: kul bytes delivered = 7 + 0 = 7 = file size. ✔ Loop sahi se terminate hota hai jaise hi 0 dikhta hai. ✔

Example 5 — short-write loop (cell H)

Worked example Statement

Tumhe count = 300-byte buffer write karna hai, lekin pehla write sirf 120 bytes hi manage karta hai. Robust loop kaam kaise khatam karta hai, aur agar baad ki har call 90 bytes write kare toh total kitne write calls?

Forecast: pehli call ke baad kitne bytes bachte hain, aur total kitne calls?

Call 1 ke baad: total = 120, remaining = 300 - 120 = 180. Agla write buf + 120 se count - total = 180 bytes ke liye shuru hoga. Yeh step kyun? Tumhe buffer ke unwritten part se resume karna hai — buf se dobara likhna galat hoga.
Call 2: 90 write karta hai → total = 210, remaining 90.
Call 3: 90 write karta hai → total = 300, remaining 0 → loop exit karta hai. Yeh step kyun? Loop condition total < count sirf tab false hoti hai jab sab kuch likh diya jaye.
Total calls = 3 (120 + 90 + 90 = 300). Yeh step kyun? Production code kabhi assume nahi karta ki ek write kaafi hai — ek signal ya full pipe kisi bhi call ko chop kar sakta hai.

Verify: 120 + 90 + 90 = 300 = count, aur \lceil arithmetic \rceil exactly 3 non-error calls deta hai. ✔

Example 6 — missing file par `open` (cell I, G)

Worked example Statement

File ghost.txt exist nahi karti. Compare karo open("ghost.txt", O_WRONLY) versus open("ghost.txt", O_WRONLY | O_CREAT, 0644).

Forecast: kaunsa -1 return karta hai?

O_CREAT ke bina: kernel path walk karta hai, koi inode nahi milta, aur -1 return karta hai with errno = ENOENT ("No such file"). Koi file nahi banti. Yeh step kyun? O_WRONLY intent to write declare karta hai, permission to create nahi. Creation ek alag flag hai.
O_CREAT ke saath: missing file permission bits 0644 ke saath create hoti hai (owner read/write, others read), aur ek valid fd (sabse chhota unused, e.g. 3) return hota hai. Yeh step kyun? mode argument (0644) sirf tab consult hota hai jab O_CREAT actually file create karta hai.
-1 ko handle karna: fd use karne se pehle hamesha return value par branch karo; -1 ko fd ki tarah read/write mein use karna khud ek error hai (cell G). Yeh step kyun? Ek failed open tumhe koi valid handle nahi deta — aage badhne se downstream sab kuch corrupt ho jaata hai.

Verify: pehla form → -1; doosra form → \geq 0. Convention "smallest unused fd" ka matlab hai stdin/stdout/stderr (0/1/2) ke saath, ek fresh fd 3 hai. ✔

Example 7 — fds leak karte karte exhaustion (cell J, limiting value)

Used slots count karo. fds 0,1,2 stdin/stdout/stderr hain → 3 used, 1024 - 3 = 1021 free. Yeh step kyun? Limit sab open descriptors count karta hai, including teeno inherited wale.

Har open ek slot consume karta hai (returns 3, phir 4, 5, … 1023). 1021 successful opens ke baad table full ho jaata hai. Yeh step kyun? close ke bina, reference count kabhi drop nahi karta, toh slots kabhi return nahi hote.

Agla (1022nd) open fail hota hai with -1, errno = EMFILE ("Too many open files"). Yeh step kyun? Isliye descriptors leak karna eventually ek long-running server ko tod deta hai — dekho ulimit and resource limits.

Verify: successful opens = 1024 - 3 = 1021; 1022nd fail hota hai. ✔ Sabse bada fd hand out kiya = 1023 (last free index). ✔

Example 8 — concurrent append logging (real world) (cell K)

Worked example Statement

Do processes dono log.txt ko O_WRONLY | O_CREAT | O_APPEND ke saath open karte hain aur har ek ek 8-byte line "started\n" write karta hai. File pehle empty thi. Dono lines ke byte offsets kya hain, aur kya woh ek doosre ko clobber kar sakte hain?

Forecast: kya writes overlap karte hain?

O_APPEND semantics. Har write atomically current EOF tak seek karta hai, phir write karta hai. Seek+write kernel ki nazar mein ek indivisible step hai. Yeh step kyun? Atomicity exactly yahi cheez hai jo do writers ko same offset choose karne se rokti hai.
Process P1 pehle write karta hai (maan lo): EOF 0 hai → bytes 0–7 write karta hai, EOF 8 ho jaata hai.
Process P2 write karta hai: EOF ab 8 hai → bytes 8–15 write karta hai, EOF 16 ho jaata hai. Yeh step kyun? Kyunki seek-to-EOF har atomic write ke andar hota hai, P2 kabhi back on 0 nahi land kar sakta.
Final size = 8 + 8 = 16 bytes, do clean lines.

Verify: total bytes = 16, offsets [0,8) aur [8,16) disjoint hain (koi overlap nahi) ordering ke bawajood. ✔ O_APPEND ke bina, dono 0 tak seek kar sakte the aur ek 8-byte clobbered file produce karte — yahi bug yeh flag prevent karta hai. ✔

Example 9 — exam twist: `O_APPEND` ke saath mixed `SEEK_CUR` (cell L)

Worked example Statement

Ek 50-byte file O_RDWR se open hai (no append). Tum karte ho: lseek(fd, 10, SEEK_SET), read(fd, buf, 5), phir lseek(fd, -3, SEEK_CUR). Final offset kya hai?

Forecast: teeno steps mein bookmark track karo.

lseek(fd, 10, SEEK_SET): offset = 10 (absolute). Yeh step kyun? Ek known starting bookmark establish karo.
read(..., 5): bytes 10–14 read karta hai, offset 10 + 5 = 15 tak advance hota hai. Yeh step kyun? read bookmark ko uske return value (5, since 5 < 50) se move karta hai.
lseek(fd, -3, SEEK_CUR): origin current offset 15 hai → newpos = 15 + (-3) = 12. Yeh step kyun? SEEK_CUR negative offset ke saath relative rewind karta hai — file start se nahi, balki jahan tum abhi ho wahan se.
Final offset = 12.

Verify: chain = 10 \xrightarrow{+5} 15 \xrightarrow{-3} 12, aur 0 \leq 12 \leq 50. ✔ (Note: agar file O_APPEND hoti, toh read offset phir bhi kaam karta, lekin writes is bookmark ko ignore karke EOF par jump kar jaate — ek classic trap.) ✔

Case-coverage check

Recall Kya humne har matrix cell hit kiya?

A ::: Example 1 (SEEK_SET forward) B ::: Example 2 (SEEK_END negative, incl. invalid -25) C ::: Example 3 (seek past EOF → sparse hole) D ::: Examples 1 & 2 (offset at boundaries 0 / size) E ::: Example 4 (short read, n < count) F ::: Example 4 (read returns 0 = EOF) G ::: Examples 6 & 7 (return -1, errno set) H ::: Example 5 (short-write loop) I ::: Example 6 (missing file, no O_CREAT → ENOENT) J ::: Example 7 (fd exhaustion → EMFILE) K ::: Example 8 (concurrent O_APPEND logging) L ::: Example 9 (mixed SEEK_CUR arithmetic)

Is page ke saath saath yeh bhi open rakhna chahoge: System calls and the kernel boundary, File descriptor table, File system & inodes, aur buffered contrast ke liye Buffered I/O (fopen/fread). Concurrency example Pipes and sockets se connect karta hai (jahan short reads norm hain, exception nahi).