ftruncate()

What ftruncate() Actually Changes

ftruncate() changes the length of an already open file, so the call affects the file object behind the descriptor rather than the pathname. When the new size is smaller, bytes past the truncation point are discarded. When the file grows, the added region is typically read as zeros until written.

This matters because truncation is not a cosmetic metadata update. It can remove live content, create sparse or zero-filled space, and alter what later readers, parsers, or synchronisation routines see. The effect is immediate once the call succeeds, so any code that assumes the old length still exists is operating on stale state.

File-Descriptor Scope and Access Control

The security boundary for ftruncate() is the file descriptor, not the visible filename. A process needs a descriptor with permission to resize that file, which means the practical control point is how the descriptor was obtained and what access mode it carries.

That makes this call part of file access control in a very direct sense. A process that can write to, or otherwise legitimately manipulate, a descriptor may be able to shorten or extend the underlying file even when the surrounding application logic did not intend that outcome.

Because the descriptor governs authority, truncation is often a downstream consequence of broader write access, shared handles, inherited descriptors, or overly permissive file management logic. The key question is not simply whether a process can open the file, but whether it can also change its size without violating application expectations.

Operational Uses and Failure Modes

ftruncate() is commonly used for log rotation, preallocation, cache management, temporary-file handling, and resetting a file before rewrite. In those patterns it is a legitimate performance and lifecycle tool, but it must be used with care because truncation can destroy data that other code still expects to persist.

Failure modes usually come from coordination gaps: one component truncates a file while another is still reading it, or a writer assumes the file contents remain intact after a size change. That can produce data loss, partial records, parse errors, stale offsets, or application crashes if length checks and file-position assumptions are not handled correctly.

Growing a file with ftruncate() can also be unsafe if the program assumes the newly created region contains meaningful data. It usually reads as zero bytes, which is useful for deterministic initialisation, but dangerous if the application treats zero-filled space as already validated content.

Security and Integrity Implications

From a security perspective, the main concern is integrity. If an attacker, compromised process, or buggy component can reach a descriptor with resize authority, they may be able to erase evidence, tamper with application state, corrupt configuration, or invalidate records that other systems rely on.

Truncation can also create confusing detection conditions. A file that suddenly shrinks may look like routine maintenance, but it can equally be a sign of sabotage, malicious cleanup, or an application fault that rewrote the wrong target. The impact depends on what the file represents: logs, credentials caches, state databases, spool files, or content pipelines all fail differently when size changes unexpectedly.

For sensitive data, truncation does not guarantee secure deletion on its own, because it changes the logical length rather than proving every underlying storage block has been erased. That distinction matters when organisations need defensible disposal or tamper evidence rather than only a smaller file.

Risk and Threat Considerations

Uncontrolled truncation can become a data-destruction primitive, especially when a process can reuse an existing descriptor or inherit one it should not control. The risk is highest where a file carries security-relevant state, audit data, or application-critical records that other components trust.

Failure mechanism: A process with resize authority shortens a file and removes bytes that downstream components still depend on, or extends it in a way that creates misleading zero-filled content. This can hide activity, break integrity checks, or cause readers to operate on invalid assumptions about the file’s contents and length.

Impact: The result can be loss of records, corrupted state, failed recovery, broken audit trails, and in some systems a stepping stone to persistence or concealment because evidence or configuration has been altered at the storage layer.

Practitioner Guidance

Why practitioners should care: ftruncate() is a low-level call with high blast radius, so it should be treated as a privileged file operation rather than a routine helper. Review which components can obtain writable file descriptors, and assume any resize-capable handle can change more than just the file length.

What to watch for: Pay attention to unexpected size changes in logs, state files, queues, and caches, especially where another process may still be reading the file. In reviews, trace descriptor provenance and ownership, not just pathname permissions, because that is what determines who can actually resize the file.