What is a File Descriptor Table?
Learn what a file descriptor table is, how it maps to the open file table, and how fork() and dup2() interact with it.
Expected Interview Answer
A file descriptor table is a per-process array maintained by the kernel that maps small integers (file descriptors), which a process uses in system calls, to entries in the kernel’s open file table, letting each process reference open files, sockets, and pipes cheaply through numbers instead of full kernel objects.
When a process calls open(), the kernel finds the lowest unused integer slot in that process’s file descriptor table and stores a pointer from that slot into a shared open file table entry, which itself points to the underlying inode or vnode. Every subsequent read(), write(), or close() call from the process passes just that small integer, and the kernel dereferences it through the table to find the real file state. Because the table is per-process, two processes can have the same descriptor number (say, 3) pointing at completely different files, and file descriptors 0, 1, and 2 are reserved by convention for stdin, stdout, and stderr. On fork(), the child inherits a copy of the parent’s file descriptor table, with entries pointing at the same open file table entries, which is why both processes share a file offset for inherited descriptors but each can close its own copy independently.
- Explains how small integers stand in for kernel file objects
- Clarifies why 0, 1, 2 are reserved for stdin/stdout/stderr
- Shows why fork() shares open file table entries but not descriptor slots
- Foundation for understanding dup(), redirection, and file descriptor limits
AI Mentor Explanation
A file descriptor table is like a scorer’s personal numbered pegboard where each peg number stands for one match currently being tracked, rather than the scorer rewriting the full scorecard every time. Peg 3 for the scorer at Ground A might refer to a completely different match than peg 3 for the scorer at Ground B, because each scorer keeps an independent pegboard. When a scorer hands duties to an assistant (fork), the assistant gets a copy of the pegboard pointing at the very same live scorecards, so both can call out peg 3 and mean the same match.
Step-by-Step Explanation
Step 1
open() is called
The process requests a file, and the kernel finds the lowest free integer slot in that process's file descriptor table.
Step 2
Slot bound to open file table entry
The chosen slot stores a pointer to a new (or existing) entry in the kernel-wide open file table, which tracks the file offset and access mode.
Step 3
Integer returned to userspace
The small integer is handed back; every later read(), write(), lseek(), or close() call references the file purely through that number.
Step 4
Table entry cleared on close()
close() clears the process's slot; the open file table entry itself is only freed once no descriptor anywhere still references it.
What Interviewer Expects
- A clear statement that the table is per-process and maps small integers to kernel file state
- Knowledge of the reserved descriptors 0, 1, 2 for stdin/stdout/stderr
- Understanding that fork() copies the table but shares open file table entries
- Awareness of the per-process descriptor limit (RLIMIT_NOFILE / ulimit -n)
Common Mistakes
- Confusing the per-process file descriptor table with the system-wide open file table
- Assuming the same descriptor number always means the same file across processes
- Thinking fork() gives the child independent file offsets for inherited descriptors
- Forgetting that descriptors are reused (lowest-free-slot) after close()
Best Answer (HR Friendly)
“A file descriptor table is basically a small numbered list the operating system keeps for every running program, mapping simple numbers like 3 or 4 to the actual open files, sockets, or pipes that program is using. It lets programs refer to files with cheap little numbers instead of passing around complex file information every time, and each program’s list is independent, which is why the same number can mean totally different files in two different programs.”
Code Example
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
int main(void) {
int fd = open("data.txt", O_RDONLY); /* kernel picks lowest free slot */
if (fd < 0) {
perror("open");
return 1;
}
printf("Got file descriptor: %d\n", fd); /* often 3, since 0,1,2 are taken */
char buf[64];
ssize_t n = read(fd, buf, sizeof(buf)); /* fd looked up in the table each call */
printf("Read %zd bytes\n", n);
close(fd); /* slot freed, reusable by the next open() */
return 0;
}Follow-up Questions
- What is the difference between a file descriptor and an inode?
- What happens to file descriptors when a process calls fork()?
- How does dup2() manipulate the file descriptor table?
- What is RLIMIT_NOFILE and how would you raise it?
MCQ Practice
1. What does a file descriptor table map?
The file descriptor table is a per-process array mapping small integers to open file table entries maintained by the kernel.
2. Which descriptors are reserved by convention?
By convention, descriptor 0 is stdin, 1 is stdout, and 2 is stderr, and shells rely on this ordering.
3. After fork(), what do the parent and child share for inherited descriptors?
fork() copies the descriptor table, but both copies point at the same open file table entry, so the file offset is shared.
Flash Cards
What is a file descriptor table? — A per-process kernel array mapping small integers to entries in the open file table.
Which descriptors are reserved by convention? — 0 (stdin), 1 (stdout), 2 (stderr).
How does fork() affect the table? — The child gets a copy of the table, with entries pointing at the same open file table objects as the parent.
How does the kernel pick a new descriptor number on open()? — It assigns the lowest currently unused integer slot in that process's table.