Re: Clear new space in fseek extended patches

[Nick Clifton <nickc at redhat dot com>]

Hi DJ,

: >   I am planning to apply the patch below unless there are any
: >   objections.
: 
: I object to the logic.  The only time you should write out the zeros
: is if you *write* after an fseek.  Merely fseeking past EOF shouldn't
: modify the file.

Err, I thought that fseeking past the end of a file physically extended
it, and that when you close the file it will always have the extended
length, regardless of whether you have written into the new area or
not.  In fact I thought that the only way to restore a file's orginal
length after fseeking past its end was to use ftruncate.

Hence the logic is correct.  If the fseek tries to go past the end of
the file (and the file has been opened for writing, so it can be
extended), then initialise the new area with zeros, because the new
space will be attached to the file even in no further writes are made
to the file.

: You will also find a severe performance loss if you do
: fseek/ftell/fseek on every fseek,

Well it is only in the cases of OSes that do not support zeroing
extended file spaces, which is not common...

: especially since we seek a lot during *reads*.

True, but that I am not sure how often that case will actually
arise.  Most BFDs are opened either for reading or for writing, and
the ones that are opened for writing are not read from.
 
: Cygwin has a similar fix, but it uses this logic:
: 
: * When seeking, set a flag on that file that says we seeked.
: * When writing, if the flag is set, check for seek past EOF and
:   fill.  Then reset the flag.

This fails if no write occurs after the seek.

Cheers
	Nick