Mail Archives: cygwin/1998/07/11/05:51:47
Geoffrey Noer (noer AT cygnus DOT 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 DOT delvecchio AT analog DOT com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -