B19: cp corrupts files with lots of zeros (Win95)

B19: cp corrupts files with lots of zeros (Win95)

[Vince Del Vecchio]

This seems to have been reported before in various forms, but I have
never seen any official response and it doesn't seem to have been fixed.
It doesn't seem to be in the FAQ.

This is with b19.1 on Win95.

Create a file with a lot of zeros in it.  I did this with:
  perl -e "print qq{\0} x 20480, qq{\n}" > /tmp/mostly-empty
Now copy it using cp
  cp /tmp/mostly-empty /tmp/full-of-garbage
Now compare
  diff /tmp/mostly-empty /tmp/full-of-garbage
Binary files /tmp/mostly-empty and /tmp/full-of-garbage differ

(If it doesn't work, try again with a different second filename.
Sometime you get lucky and it works.)

This seems a bit absurd to me.  How can you rely on the tools if
cp silently corrupts your files?

The main problem seems that lseek past EOF doesn't work the same as on
Unix (or even as on NT).  I sent in a bug report, including a patch,
just about a year ago, but it seems to have been ignored.  (I also
reported the HAVE_SETMODE problem with diff, among other things, which
seems to have just been noticed again and fixed -- you'll have to excuse
me for being a little bitter.)  You can find it by searching for "lseek"
in the mailing list archives.

-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".

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

[Vince Del Vecchio]

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".

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

[DJ Delorie]

Vince Del Vecchio wrote:
> Could someone also briefly describe what the semantics will be in the
> next DLL?

The new version will only flag the file when you call lseek().  If you
then call write(), it will know that it followed an lseek(), and
will test to see if the current file pointer is beyond eof.  If
so, it seeks back to eof and writes out zeros to fill the gap.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

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

[Geoffrey Noer]

On Fri, Jul 10, 1998 at 06:42:25PM -0400, Vince Del Vecchio wrote:
[...]
> 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")?
[...]

Sorry about that.  Someone here is going to replace htdig with another
search engine in the future.  I've (just) updated the databases
manually and will try to do so again if the new one isn't up before
too long...

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: B19: cp corrupts files with lots of zeros (Win95)

[Sergey Okhapkin]

Christopher G. Faylor wrote:
> Sorry for the lack of response.  The problem with seeking past EOF
> has been fixed in our development tree, which means that it may
> be fixed in Sergey's coolview soon.

Done :-) Yesterday.

BTW, new ssh-1.2.26 binaries and the diff uploaded.

-- 
Sergey Okhapkin, http://www.lexa.ru/sos
Moscow, Russia


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

Re: B19: cp corrupts files with lots of zeros (Win95)

[Christopher G. Faylor]

In article <237C350B0201A8C0005.cygnus.gnu-win32@galahad.wisent.de>,
Vince Del Vecchio <vince.delvecchio@analog.com> wrote:
>This seems to have been reported before in various forms, but I have
>never seen any official response and it doesn't seem to have been fixed.
>It doesn't seem to be in the FAQ.
>
>This is with b19.1 on Win95.
>
>Create a file with a lot of zeros in it.  I did this with:
>  perl -e "print qq{\0} x 20480, qq{\n}" > /tmp/mostly-empty
>Now copy it using cp
>  cp /tmp/mostly-empty /tmp/full-of-garbage
>Now compare
>  diff /tmp/mostly-empty /tmp/full-of-garbage
>Binary files /tmp/mostly-empty and /tmp/full-of-garbage differ
>
>(If it doesn't work, try again with a different second filename.
>Sometime you get lucky and it works.)
>
>This seems a bit absurd to me.  How can you rely on the tools if
>cp silently corrupts your files?
>
>The main problem seems that lseek past EOF doesn't work the same as on
>Unix (or even as on NT).  I sent in a bug report, including a patch,
>just about a year ago, but it seems to have been ignored.  (I also
>reported the HAVE_SETMODE problem with diff, among other things, which
>seems to have just been noticed again and fixed -- you'll have to excuse
>me for being a little bitter.)  You can find it by searching for "lseek"
>in the mailing list archives.

Sorry for the lack of response.  The problem with seeking past EOF
has been fixed in our development tree, which means that it may
be fixed in Sergey's coolview soon.
-- 
cgf@cygnus.com             "Everything has a boolean value, if you stand
http://www.cygnus.com/      far enough away from it."  -- Galena Alyson Canada
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

B19: cp corrupts files with lots of zeros (Win95)

[Vince Del Vecchio]

This seems to have been reported before in various forms, but I have
never seen any official response and it doesn't seem to have been fixed.
It doesn't seem to be in the FAQ.

This is with b19.1 on Win95.

Create a file with a lot of zeros in it.  I did this with:
  perl -e "print qq{\0} x 20480, qq{\n}" > /tmp/mostly-empty
Now copy it using cp
  cp /tmp/mostly-empty /tmp/full-of-garbage
Now compare
  diff /tmp/mostly-empty /tmp/full-of-garbage
Binary files /tmp/mostly-empty and /tmp/full-of-garbage differ

(If it doesn't work, try again with a different second filename.
Sometime you get lucky and it works.)

This seems a bit absurd to me.  How can you rely on the tools if
cp silently corrupts your files?

The main problem seems that lseek past EOF doesn't work the same as on
Unix (or even as on NT).  I sent in a bug report, including a patch,
just about a year ago, but it seems to have been ignored.  (I also
reported the HAVE_SETMODE problem with diff, among other things, which
seems to have just been noticed again and fixed -- you'll have to excuse
me for being a little bitter.)  You can find it by searching for "lseek"
in the mailing list archives.

-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".

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