This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


"Corinna Vinschen" <corinna-cygwin@cygwin.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@cygwin.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]