What is the Open File Table?
Learn what the open file table is, how it differs from the file descriptor table, and how dup() and fork() share entries.
Expected Interview Answer
The open file table is a kernel-wide (system-wide) structure of entries, each tracking the current file offset, access mode, and status flags for one open() call, sitting between the per-process file descriptor table and the underlying inode so that multiple descriptors can share or independently track the same file.
Every time any process calls open() on a path, the kernel allocates a new open file table entry that records the file offset, the mode it was opened with (read, write, append), and a pointer down to the file’s inode (or vnode) which holds the actual data location and permissions. A process’s file descriptor table entry is just a pointer into this system-wide table, so if a process opens the same file twice, it gets two separate open file table entries with two independent offsets, but if a descriptor is duplicated via dup() or inherited via fork(), both descriptors point at the very same open file table entry and therefore share one offset. This three-level structure — per-process descriptor table, system-wide open file table, and the inode table below it — is exactly what explains why writing through one duplicated descriptor advances the read position seen by the other, while two independent open() calls on the same file do not affect each other’s position.
- Explains why dup()'d descriptors share a file offset but independent open() calls do not
- Clarifies the three-level chain: descriptor table → open file table → inode
- Foundation for understanding shared file position semantics in pipes and redirection
- Explains reference counting that keeps a file open after unlink()
AI Mentor Explanation
The open file table is like a stadium’s single shared ledger of currently active innings, where each ledger row tracks the exact ball-by-ball position and mode (batting or bowling review) for one active viewing session, separate from the master scorecard archive (the inode) underneath. Two separate scorers who each independently start watching the same match get two separate ledger rows with independent ball counts, but if one scorer hands their ledger row directly to an assistant, both now track the exact same ball position together. This is why cloned viewing sessions stay in sync while independently started ones do not.
Step-by-Step Explanation
Step 1
open() allocates an entry
The kernel creates a new open file table entry recording the offset (starting at 0), access mode, and status flags.
Step 2
Entry points to the inode
The entry holds a pointer down to the file's inode/vnode, which stores the actual data blocks and metadata.
Step 3
Descriptor table points to the entry
The calling process's file descriptor slot stores a pointer up to this open file table entry, not to the inode directly.
Step 4
Sharing via dup()/fork()
Duplicating a descriptor makes a second descriptor point at the same open file table entry, so both share one offset and mode.
What Interviewer Expects
- Recognition that the open file table is system-wide, not per-process
- Clear distinction between the open file table and the inode/vnode table below it
- Explanation of why dup()'d descriptors share an offset but independent open() calls do not
- Awareness that reference counts on this table keep data alive after unlink()
Common Mistakes
- Conflating the open file table with the per-process file descriptor table
- Assuming two independent open() calls on the same path share a file offset
- Forgetting that the inode is a separate, lower-level structure from the open file table entry
- Not knowing why a deleted-but-open file still occupies disk space (reference count keeps the inode alive)
Best Answer (HR Friendly)
“The open file table is a system-wide list the kernel keeps of every file currently open by any process, and each entry remembers exactly where in the file you currently are and how it was opened. When you open the same file twice separately, you get two independent positions in that file, but if a file handle is copied — like when a program forks — both copies share the exact same position, which is why they stay in sync.”
Code Example
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
int main(void) {
int fd1 = open("log.txt", O_RDONLY); /* new open file table entry, offset = 0 */
int fd2 = open("log.txt", O_RDONLY); /* ANOTHER new entry, offset = 0, independent */
char buf[16];
read(fd1, buf, 16); /* advances fd1's offset only */
/* fd2's offset is still 0 -- separate open file table entries */
int fd3 = dup(fd1); /* fd3 points at the SAME entry as fd1 */
read(fd3, buf, 16); /* advances the shared offset */
/* now fd1's next read continues from where fd3 left off */
close(fd1); close(fd2); close(fd3);
return 0;
}Follow-up Questions
- What is the difference between the open file table and the file descriptor table?
- Why does an unlinked but open file still occupy disk space?
- How does dup2() affect open file table sharing during shell redirection?
- What happens to the open file table entry's reference count when a process exits?
MCQ Practice
1. The open file table is scoped at which level?
The open file table is a single, kernel-wide structure shared across all processes, unlike the per-process file descriptor table.
2. If a process calls open() twice on the same path, what happens to the file offsets?
Each open() call creates a distinct open file table entry, so the two descriptors track the file position independently.
3. What does dup() cause two descriptors to share?
dup() creates a new descriptor that points at the exact same open file table entry as the original, so they share the file offset.
Flash Cards
What is the open file table? — A system-wide kernel structure of entries tracking offset, mode, and a pointer to the inode for each open() call.
Do two separate open() calls on the same file share an offset? — No — each gets its own independent open file table entry and offset.
What does dup() share between descriptors? — The same open file table entry, so the file offset and mode are shared.
What sits below the open file table in the chain? — The inode (or vnode) table, which holds the actual file data and metadata.