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

KYA: open sabse chhota unused file descriptor return karta hai. 0 kyun nahin: ek normal program mein fds 0, 1, 2 pehle se stdin, stdout, stderr ke liye occupied hain. Toh sabse chhota unused wala 3 hai. Answer: 3.

Error nahin hai. 0 ka return matlab hai end of file (EOF) — current offset par aur koi bytes nahin hain. Errors -1 return karti hain (errno set hokar). Toh 0 = "cleanly khatam", -1 = "toot gaya".

Yeh ==-1== return karta hai aur errno = ENOENT set karta hai. O_CREAT ke bina, open koi missing file nahin banayega — O_WRONLY sirf yeh describe karta hai ki tum kaise access karna chahte ho, yeh nahin ki use banana hai ya nahin.

SEEK_END kya karta hai: yeh $\text{newpos}=\text{size}+\text{offset}$ compute karta hai. $\text{newpos}=20+(-4)=16.$ Offset arrow byte 16 par land karta hai. Phir 4 bytes ka read indices 16, 17, 18, 19 cover karta hai — exactly last four bytes — aur EOF par ruk jaata hai.

Step 1: 10 bytes ka read offset ko apne return value se automatically advance karta hai: $0+10=10$. Step 2: SEEK_CUR matlab $\text{newpos}=\text{cur}+\text{offset}=10+5=15$. Answer: 15. (Bytes 10,11,12,13,14 skip ho gaye, kabhi read nahin hue.)

Yeh current offset mein 0 add karta hai, toh yeh kuch change nahin karta lekin current offset return karta hai. Yeh standard trick hai "main abhi kahan hoon?" poochhne ke liye bina move kiye. WHY kaam karta hai: lseek hamesha newpos return karta hai, aur yahan $\text{newpos}=\text{cur}+0=\text{cur}$.

Step 1 (seek): SEEK_SET offset directly set karta hai: $\text{newpos}=25$ — yeh current 20-byte end se aage hai. Yeh allowed hai. Step 2 (write): offset 25 par 2 bytes likhne se 'A' 25 par aur 'B' 26 par aa jaata hai. Naya size = last written index + 1 = $26+1=27$. Gap (bytes 20–24): kabhi nahin likha gaya → kernel unhe implicit zero bytes treat karta hai. Yeh ek sparse file hai — ek "hole" jo \0 ke roop mein read back hota hai aur koi disk blocks occupy nahin karta.

WHY normally dangerous: O_APPEND ke bina, har process ka apna offset hota hai. Dono "offset 40 par likho" compute kar sakte hain, toh ek doosre ko overwrite kar deta hai. WHY O_APPEND fix karta hai: yeh flag har write ko atomically "seek-to-EOF phir write" ek single indivisible kernel step mein karta hai. Process A 40 par seek karta hai, 8 likhta hai (EOF ab 48); process B ka write phir 48 par seek karta hai, 8 likhta hai (EOF ab 56). Kyunki seek+write interrupt nahin ho sakta, do offsets kabhi collide nahin kar sakte → dono lines survive karti hain, back to back.

Sirf buf[0] .. buf[39] (pehle 40 bytes, return value) mein real file data hai. Slots buf[40] .. buf[99] untouched hain — wahi puraana garbage hai jo pehle tha. Toh tumhe n (=40) use karna chahiye, kabhi count (=100) nahin. 100 likhne par 60 bytes junk leak ho jaata.

ssize_t total = 0, n;
while (total < count) {
    n = write(fd, buf + total, count - total);
    if (n < 0) break;            // real error → bail
    total += n;                  // advance past bytes already written
}

WHY loop: ek single write request se kam transfer kar sakta hai (disk pressure, signals). Production code kabhi assume nahin karta ki ek call kaam khatam kar dega.

Calls ki count 4096 bytes ke liye, 1500 per call:

• Call 1: 1500 likhta hai → total 1500 (remaining 2596)
• Call 2: 1500 likhta hai → total 3000 (remaining 1096)
• Call 3: 1096 maangta hai; short write caps at... lekin sirf 1096 bache hain, toh 1096 likhta hai → total 4096, loop khatam.

Answer: 3 calls.

int in  = open(src, O_RDONLY);
if (in < 0) return -1;                                  // src missing → -1
int out = open(dst, O_WRONLY | O_CREAT | O_TRUNC, 0644);// create/empty dst
if (out < 0) { close(in); return -1; }
 
char buf[4096];
size_t remaining = k;
while (remaining > 0) {
    size_t want = remaining < sizeof buf ? remaining : sizeof buf;
    ssize_t n = read(in, buf, want);
    if (n <= 0) break;             // n==0 EOF (src shorter than k) → stop; n<0 error
    ssize_t w = 0;
    while (w < n) {                // robust write of exactly the bytes we read
        ssize_t m = write(out, buf + w, n - w);
        if (m < 0) { close(in); close(out); return -1; }
        w += m;
    }
    remaining -= n;
}
close(in); close(out);
return 0;

KEY design points: read ke return n par loop karo (k par nahin); n == 0 (EOF) par cleanly ruko jab src chhota ho; short-write loop nest karo; O_TRUNC koi bhi purana dst khali karta hai; dono fds close karo.

KYA scarce hai: per-process file-descriptor table ka hard cap hai (ulimit -n = 1024). Teen fds (0,1,2) pre-occupied hain, 1024 - 3 = 1021 usable slots bachte hain. WHY leaks accumulate hote hain: har errored request exactly ek fd leak karta hai (kabhi return nahin hota). Leaks per request $=\frac{1}{8}$. KAB toot-ta hai: yeh tab fail karta hai jab 1021 free slots sab leak ho jaate hain: $\text{requests}=1021÷\frac{1}{8}=1021\times 8=8168.$ 8168th request ke aaspaas agla open ==-1== return karta hai errno = EMFILE ke saath ("too many open files"). Fix: har path par close karo, error paths including.

Arrow ko step by step track karo:

1. SEEK_SET 8 → offset $=8$.
2. read 5 (5 return karta hai) → offset advance hota hai: $8+5=13$.
3. SEEK_CUR -3 → $13+(-3)=10$.
4. SEEK_END 0 → $\text{size}+0=20+0=20$.

Offsets: 8 → 13 → 10 → 20. Final answer 20 (EOF).

dup: descriptor copy karta hai, toh fd aur fd2 same open file description ko point karte hain — same offset arrow. Ise fd2 ke through move karo aur fd bhi woh move dekhta hai (ek arrow, do naam). Do opens: har open ek alag open file description allocate karta hai, har ek ka apna offset arrow. Ek ko move karne se doosra untouched rehta hai. Reference count: description sirf tab free hoti hai jab iske saare fds close ho jaate hain; count isliye hai ki ek stray dup'd fd file ko "alive" rakhta hai jab tak har copy close na ho jaaye.

Is page ka har question actually yeh hai "arrow kahan hai, aur kitne claim-tickets ise point kar rahe hain?" read/write arrow ko apne return value se forward dhakelte hain; lseek ise simple arithmetic se teleport karta hai (SET=absolute, CUR=relative, END=size se); close ek ticket waapis deta hai aur sirf tab saaf karta hai jab last ticket chali jaaye.