This is the mail archive of the
mailing list for the Cygwin project.
Re: Sparse file criteria malfunction - binutils produces sparse .exe& .dll files
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Max Bowsher <maxb at ukf dot net>
- Cc: cygwin at cygwin dot com
- Date: Thu, 5 Jun 2003 12:41:18 -0400 (EDT)
- Subject: Re: Sparse file criteria malfunction - binutils produces sparse .exe& .dll files
- Reply-to: cygwin at cygwin dot com
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
> >> 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
> >> 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.
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
|\ _,,,---,,_ email@example.com
ZZZzz /,`.-'`' -. ;-;;,_ firstname.lastname@example.org
|,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