On 04.07.2009 01:11, Eleanor McHugh wrote:
> On 3 Jul 2009, at 23:06, Greg Willits wrote:
>> 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?
> 
> Unfortunately you're getting lucky. A seek adjusts the file pointer  
> but doesn't write anything to disk so whilst your 'unused' bytes won't  
> be changing value as a result of writing data to the file unless you  
> write the full record, you can't rely on them not having a value other  
> than zero if you don't.

Actually it should not matter what those bytes are.  Your record format 
should make sure that you exactly know how long an individual record is 
- as Ellie pointed out:

> Also you have to consider that zero may itself be a valid data value  
> within a record :)

Oh, the details. :-)

Here's another one: if your filesystem supports sparse files and the 
holes are big enough (at least spanning more than one complete cluster 
or whatever the smallest allocation unit of the filesystem is called) 
those bytes might not really come from disk, in which case - when read - 
they are usually zeroed.  But I guess this is also implementation dependent.

One closing remark: using "tail" to look at a binary file is probably a 
bad idea in itself.  "tail" makes certain assumptions about what a line 
is (it needs to in order to give you N last lines).  Those assumptions 
are usually incorrect when using binary files.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/