Re: lseek past EOF doesn't append zeros under Windows 95

[Vince Del Vecchio <vince dot delvecchio at analog dot com>]

Geoffrey Noer (noer@cygnus.com) said:

> On Sat, Jun 20, 1998 at 05:29:00PM +0200, Michael Hirmke wrote:
> > [...]
> > >but under Windows 95 the cygwin32 package does not behave this
> > >way.  The gap is filled with garbage.  One package that depends
> > >on the zeroing behavior is db-1.86.  Here is a test program:
> > 
> > This is a well known misbehaviour of Windows 95.
> > AFAIK there is nothing at the moment, you can do about it.
> 
> FYI, this has just been fixed in the current Cygwin32 development
> sources and will be in future versions of the DLL.

Well, I feel like a bit of a fool now.  As you can tell, I hadn't been
reading the list before I just reported this exact same bug.

Is there someone to complain to about the fact that searching the
archives (using http://www.cygnus.com/htdig/searchgnuwin32.html) for
"lseek" doesn't find this recent thread ("lseek past EOF doesn't append
zeros under Windows 95")?

Could someone also briefly describe what the semantics will be in the
next DLL?  I notice that the workaround which was posted extends the
file when the lseek() is done, which is not strictly correct -- the file
shouldn't actually get extended until you do a write().  I think that
proper semantics during interoperation with native programs may in fact
be impossible, and I'm just wondering how close you're getting.

Also, there is a problem in cp which is why this bug turns up there.
As I reported a year ago:

> In fileutils, ST_NBLOCKS in system.h is supposed to return the
> number of 512 byte blocks. It Cygwin32, it seems that st_blksize is
> 1024, but ST_NBLOCKS is still defined as simply the st_blocks field,
> so it is off by a factor of two.
>
> (This is why cp decides that files are sparse.)

-Vince Del Vecchio
vince.delvecchio@analog.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".