Re: Sparse file criteria malfunction - binutils produces sparse .exe& .dll files

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Thu, 5 Jun 2003, Max Bowsher wrote:

> Corinna Vinschen wrote:
> > On Thu, Jun 05, 2003 at 10:48:39AM -0500, Gary R. Van Sickle wrote:
> >> Wait, no, *100%* of Cygwin users on NTFS are negatively
> >                                               ^^^^^^^^^^
> >                                               ??????????
> >
> > I'm also on NTFS and I don't suffer, especially after the latest change.
> >
> >> Yes, now it'll be only if you write past the end of the file.  Which
> apparently
> >> binutils does.  Well, that's something I guess.
> >
> > Why does everybody fail to evidence?
> >
> > I'm having a lot of projects on my XP/NTFS system since I'm a developer
> > developing for Cygwin.   I'm running the latest DLL from CVS.
> >
> > Guess what?
> >
> > I didn't see any proof that ld or strip create sparse files.  All *.a, *.o
> > and *.exe files take as much blocks as to be expected by non-sparse files.
>
> I threw together a horrible C program to ask Windows whether a file was
> sparse. .exe and .dll files made with a 1.5.0 Cygwin are. I haven't posted
> the test program, because it is too messy.
>
> >> Let the not-so-passive-aggressive semi-namecalling begin (I suggest
> "Assistant
> >> Adjutant General Complainer JG").  But tell me where I'm wrong first.
> >
> > You're argumenting without proof.
>
> I give proof that dll/exe files are being created sparse above.
>
> Do you mean proof that sparseness of .exe files is harmful?
> Data has already been posted by me and others showing that sparse files
> consume excess disc space.
> That alone is enough for me to not want files unnecessarily sparse.
> (There is also the plausible conjecture that NTFS must do more work reading
> a sparse file - I have no test data, but since sparseness gains me nothing,
> and might lose me something, I dont like it._
>
> So, the point is, for the majority of users, sparseness gains nothing, and
> can have undesirable effects.
> Therefore, I really think it should be off by default.
>
> Max.

I've been monitoring this discussion as an outsider (i.e., most of these
issues don't affect me one way or another -- I'm not running out of disk
space, yet).  At the risk of being [bf]lamed later, two summary points:

1) The only two examples of where sparse files would be a benefit were
   Pierre Humblet's mention of the lastlog file and Vaclav Haisman's
   proprietary files that provided the original justification for the
   patch.  Neither of these requires that *all* files be made sparse,
   just that a mechanism be provided to make some files sparse (either via
   fcntl or by performing some unusual operation, such as writing past
   eof).  Max says that there is evidence that binutils performs such
   operations (on his system).  This might mean that the operation that
   was selected wasn't unusual enough.  Before anyone asks, no, I don't
   have an alternative suggestion at this point.

2) In all other details (including restricted characters in filenames),
   Cygwin uses the underlying filesystem's conventions.  If we go out of
   our way to be compatible with Linux in this aspect, why not also
   support "aux" as the filename, or support '\' in filenames?  The
   argument for not doing the latter was that we don't want to
   disassociate ourselves from the underlying filesystem, IIRC, so why go
   back on it now?

FWIW, the non-default 'sparse' option in $CYGWIN is a very nice
compromise, IMO.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/