On Tue, 25 Nov 2025, 00:20 Chet Ramey, <[email protected]> wrote: > The problem is […] whether the file `shrinking' indicates something to be > concerned about. >
Apparent shrinkage (or growth) can occur for numerous innocuous reasons, so treating it as an error may be prone to false positives. • there may be a translation layer (e.g. CR+LF→LF) so that the bytes presented by fread or read may differ from what st_size is based on; • the kernel may be unable to accurately and quickly compute the size: • the filesystem might not store the file length to bytewise precision; • the file content might be dynamically generated, so that providing an accurate size is both costly and pointless; • the file might be replaced with high rapidity (fstat would be accurate but stat would be unreliable) • the file content might be overwritten with high rapidity; to present a consistent result to read requires a specialised "write and truncate" system call. We are often advised to avoid separating "checking" from "doing", and this feels like a similar kind of split. Perhaps st_size should be treated as a strong hint rather than definitive. -Martin PS stat is often used by programs to avoid performing "costly" actions, but when stat itself becomes costly it can make performance worse overall. So it's a reasonable design decision to have st_size be a "quick estimate" rather than completely accurate. >
