Comment by colanderman
2 years ago
The file's size could have been set by the application before copying data to it. This will result in a file which reads all zeroes.
Or if it were a hardware ordering fault, remember that SSD TRIM is typically used by modern filesystems to reclaim unused space. TRIMmed blocks read as zero.
> The file's size could have been set by the application before copying data to it. This will result in a file which reads all zeroes.
Hm, is that a common approach? I thought applications mostly use fallocate(2) for that if it's for performance reasons, which does not change the nominal file size.
Actually allocating zeroes sounds like it could be quite inefficient and confusing, but then again, fallocate is not portable POSIX.
> Or if it were a hardware ordering fault
That's what I suspect might be going on here.
fseek to the (new) end and back. Avoids metadata updates on every write. Not sure how common it is but it does occur.