§39.5–39.6The File Offset, and Sharing It: lseek, fork, dup

We’ve read and written files only sequentially so far — start to finish. Sometimes, though, you need to jump to a specific spot (an index into a document, say). That requires understanding the offset that every open file carries.

39.5 Reading And Writing, But Not Sequentially

For each open file the OS tracks a current offset file offset The 'current' position stored in an open file table entry, deciding where the next read or write begins. Each read/write of N bytes advances it by N; lseek() sets it explicitly (enabling random access). lseek() only changes this in-memory variable — it does NOT itself cause a disk seek. defined in ch. 39 — open in glossary , which decides where the next read or write begins. It updates two ways. Implicitly: a read or write of N bytes adds N to the offset. Explicitly: lseek(int fd, off_t offset, int whence) sets it. The whence argument picks the reference point:

• SEEK_SET — set the offset to exactly offset bytes.
• SEEK_CUR — set it to the current offset plus offset bytes.
• SEEK_END — set it to the file size plus offset bytes.

The offset lives in the kernel’s per-open-file structure (simplified from xv6):

struct file {
  int   ref;       // reference count
  char  readable;
  char  writable;
  struct inode *ip; // which underlying file
  uint  off;        // current offset
};

These structures — all currently-open files in the system — together form the open file table open file table A system-wide table of entries, each describing one open file: which inode it refers to, whether it is readable/writable, a reference count, and the current file offset. A process's file descriptors point into this table; usually one-to-one, but entries can be shared (via fork() or dup()). defined in ch. 39 — open in glossary . Watch the offset move as a process reads a 300-byte file, then repositions with lseek:

Two opens, two offsets

If a process opens the same file twice, it gets two descriptors and two separate open file table entries — so each has its own offset, moving independently:

39.6 Shared File Table Entries: fork() and dup()

Usually the descriptor → open-file-table mapping is one-to-one; even two different processes reading the same file each get their own entry (and offset). But two important cases share a single entry.

The first is fork(). When a parent forks, the child inherits copies of the parent’s descriptors — and those copies point at the same open file table entry, so parent and child share one offset. The entry’s reference count records this; it’s freed only when both close it. Here is fork-seek.c in motion:

The relationships look like this — two private descriptor arrays converging on one shared open-file entry, which points at the inode:

The second case is dup(). It creates a new descriptor in the same process that refers to the same underlying open file as an existing one:

int fd  = open("README", O_RDONLY);
int fd2 = dup(fd);   // fd and fd2 now share one open-file entry

dup() (and especially dup2()) is the mechanism a shell uses for output redirection — point a command’s descriptor 1 at a file’s open-file entry, and its writes land in the file instead of on the screen.