(sorry this one takes some setup to explain the context of the question)
I’m using file seek to create equal fixed length rows in a disk file.
The row data itself is not fixed length, but I am forcing the seek
position to be at fixed intervals for the start of each row. So, on disk
it might look something like this:
I’m really only writing the “aaaa…” and “bbbb…” portions of the
rows with an EOL (an X here so it’s easy to see).
I have one operation step which uses tail to grab the last line of the
file. When I do that, I get something like this:
which is the empty bytes past the EOL of the line “bbb…” plus the
valid data of the following line.
After some fiddling, it became apparent that I can test the value of the
byte against zero to know if there’s data in it or not – if byte_data
== 0 so that I can trim off that leading set of zeros, but I’m not
certain those empty bytes will always be zero.
And finally my question…
So, my question is about those zeros. Does advancing the seek position
(do we still call that the “cursor”?) intentionally and proactively fill
the unsed bytes with what apparently equates to zero? OR, am I just
getting luck that my test files have used virgin disk space which yields
zeros, and the seek position just skips bytes which potentially would
contain garbage from previously used disk sectors?
Can I count on those unused bytes always being zero?