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
X-Injected-Via-Gmane: http://gmane.org/
To: cygwin AT cygwin DOT com
From: "Markus Mauhart" <markus DOT mauhart AT chello DOT at>
Subject: Re: Sparse file criteria malfunction - binutils produces sparse .exe & .dll files
Date: Thu, 5 Jun 2003 17:56:05 +0200
Lines: 55
Message-ID: <bbnp4d$vlq$1@main.gmane.org>
References: <004201c32902$3e92b020$78d96f83 AT pomello> <20030602133202 DOT GC30498 AT redhat DOT com> <bbl3cu$ph4$1 AT main DOT gmane DOT org> <20030605115804 DOT GL875 AT cygbert DOT vinschen DOT de> <bbngfu$aku$1 AT main DOT gmane DOT org> <20030605140748 DOT GS875 AT cygbert DOT vinschen DOT de>
X-Complaints-To: usenet AT main DOT gmane DOT org
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165

"Corinna Vinschen" <corinna-cygwin AT cygwin DOT com> wrote ...

> The next Cygwin version will produce sparse files only if the application
> decides to write 64K or more beyond EOF.

I have to admit that this is IMHO a significant technical improvement,
probably removing 9x% of cygwin_sparse' potential technical drawbacks;
allthough the remaining few sparse files are then still invisible from
within the traditional windows environment's filemanager, so I have to
stick with cygwin 1.3.20 ;-)


> On Thu, Jun 05, 2003 at 03:28:42PM +0200, Markus Mauhart wrote:
> > "Corinna Vinschen" <corinna-cygwin AT cygwin DOT com> wrote ...
> > > $ ./sp 2000
> > > Creating file of size 2008K
> > > st_size  :    2056192
> > > st_blocks:         24
> > > $ ls -sl sparse.test
> > > 12 -rw-r--r--    1 corinna  users     2056192 Jun  5 13:54 sparse.test
> >
> > Thanks for checking this out! What file system was used for this test ?
>
> ext3
>
> > Who manages the holes, Linux or the FS(-driver) ? AFAICS it must be the FS.
>
> The FS driver.
>
> > Does it work with ext2- or ext3-driven volume, or even a more traditional
> > unix FS ?
>
> *More* traditional than ext[23]?  Why do you want to compare an *old*
> FS with a *new* FS as NTFS is?  That's like comparing a Ford Model A
> with a modern Ford Taurus.  What is that good for?

Good question. It's about whether the old claim that this feature
(*each* file sparse !) is necessary to emulate "unix sparse files" ever
was true. AFAICS it was wrong; additionally "*each* file NTFS sparse"
was a technically wrong decission; the current choice (if "write 64K
or more beyond EOF") now seems to be a good way to emulate *modern*
unix FS capabilities, which are different from "unix sparse files",
but which are necessary for *modern* unix programs like the mentioned
movie/CD-program.
So probably you are right, when the next cygwin does what you say
("64K"), further discussion about old wrong arguments supporting
old wrong features are really good for nothing.
But nevertheless send me an email in case you find out more about
since when typical unix/linux FSs support holes inside files !


Regards,
Markus.




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