lseek

How lseek works

lseek changes the current offset associated with an open file descriptor. It tells the kernel where the next read or write should begin, which makes it a core primitive for random access, record-oriented processing, and sparse-file handling.

Because the call only updates position metadata, it is often misunderstood as a data-moving operation. In practice, the value returned by lseek reflects the new offset, so applications can confirm where subsequent I/O will land without reading or writing a byte.

Why offset control matters

Offset control is what lets software jump over headers, revisit earlier regions, append after a known boundary, or probe the size of a file. For large files, logs, disk images, and databases, that behavior is more important than sequential streaming alone.

It also matters for sparse files, where holes can exist between populated regions. A seek can move across those gaps without forcing the filesystem to allocate blocks until data is actually written.

Common uses and edge cases

Typical uses include file indexing, binary parsing, partial updates, and checking whether a file supports random access at all. On non-seekable objects such as pipes or sockets, the system call fails because there is no meaningful file position to move.

Applications also need to handle large-offset arithmetic carefully. If a program computes positions incorrectly, it may overwrite the wrong region, skip required data, or read stale content from an unexpected offset.

What lseek does not do

lseek does not copy data, flush buffers, create a file, or change file contents by itself. It only changes the process-visible offset for an already open descriptor, so any later I/O call uses that new starting point.

That distinction is important for correctness and for security reviews. A seek may enable precise access to sensitive byte ranges, but the actual exposure comes from the file permissions, the descriptor already held by the process, and the code that follows the seek.