delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/06/06/17:29:35

From: wdoyle AT bode DOT cdsp DOT neu DOT edu (Patrick Doyle)
Subject: Re: EXE has file junk in it
6 Jun 1997 17:29:35 -0700 :
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <199706061721.NAA06623.cygnus.gnu-win32@cdsp.neu.edu>
Original-To: gnu-win32 AT cygnus DOT com
In-Reply-To: <Pine.SUN.3.91.970605141040.3695A-100000@terra>
(rminnich AT sarnoff DOT com)
Original-Sender: owner-gnu-win32 AT cygnus DOT com

I thought I would add my $.02 to the discussion.  Some time ago, I
discovered that "cp" was corrupting files that it copied.  Upon
investigation, I learned that the file I was copying from had large
chunks of zero data.  The default behavior for "cp" when it notices
this condition is to create sparse files by performing an lseek()
beyond the end of the file.  On most normal operating systems, the OS
zeros the disk sectors that are allocated as a result of this
operation.  Apparently, W95 does not do this.

I solved the problem for "cp" by changing the default option for
--sparce to be NEVER (boy do I sure love having source code!!!).  I
wonder if, perhaps, the linker attempts to create a sparse file by a
similar trick.

Would it be possible/reasonable to "fix" the seek() function supplied
by CYGWIN to check for EOF and zero pad the file?

-- 
--patrick
wpd at delcomsys dot com (read as xxx AT yyy 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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019