Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<003701c31d98$7a9649d0$78d96f83@pomello>
From:	"Max Bowsher" <maxb AT ukf DOT net>
To:	<martin AT xemacs DOT org>
Cc:	<cygwin AT cygwin DOT com>
References:	<16072 DOT 892 DOT 778395 DOT 24290 AT gargle DOT gargle DOT HOWL><003901c31d8c$6ec495f0$78d96f83 AT pomello> <16072 DOT 6666 DOT 10124 DOT 338022 AT gargle DOT gargle DOT HOWL>
Subject:	Re: SPARSE files considered harmful - please revert
Date:	Mon, 19 May 2003 00:52:02 +0100
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2800.1165

Martin Buchholz wrote:
>>>>>> "Max" == Max Bowsher <maxb AT ukf DOT net> writes:
>
> Max> May I suggest a middle road? Why not let sparse files be configurable
> as a Max> $CYGWIN option? This would allow those users who actually want
> them to Max> enable them with minimal effort, but keep them off for most
> users.
>
> I suspect that SPARSE files are genuinely useful, when storing large
> files that have holes in them.  But I can't imagine one ever wanting
> to use SPARSE for all files, because most files aren't like that.  So
> I don't think sparseness is a good candidate for being put into
> $CYGWIN.

Agreed. I was just trying to find some simple compromise. Have you reviewed
the long conversation that went on in cygwin-patches in February? Based on
the ease with which this patch was accepted, I'm conjecturing that the core
developers won't want a simple reversion.

> We could have a much cleverer implementation of sparseness, if we kept
> statistics on the number and size of zero bytes in a file while it was
> being written.  When we did the close(), we could automatically
> transform it into a sparse file.  But I don't think even that should
> be the default behavior, because it would make all IO slower.

And it wouldn't achieve Vaclav Heisman's original goal, either - he wanted
to avoid the delay caused by Windows zero-filling a file when it was
initially writted to at a large offset.


Max.


--
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/

- Raw text -