This is the mail archive of the 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" <> wrote ...
> But that's a security problem, in contrast of not having allocated
> blocks at all for that hole.  Cygwin has special code which does exactly
> that, writing 0 into all blocks in the hole on 9x/Me.  Funny, but in
> 9x/Me this is a bug.  The SetFileValidData() function converts this
> into a performance gain.

But dont forget that only a process/user with "SE_MANAGE_VOLUME_NAME privilege"
gets unzeroed clusters, so (unlike with 9x/Me) this is not a security hole.

> > Otherwise, has anyone of the cygwin-is-sparse proponents the information
> > whether 'traditional unix sparse files' support unallocated holes inside
> > files ? If yes, since when ?
> I don't know since when but a simple application helps to show that Linux
> supports sparseness "just so":
> [...]
> $ gcc -o sp sp.c
> $ ./sp 200
> Creating file of size 208K
> st_size  :     212992
> st_blocks:         24
> $ ./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 ?
Who manages the holes, Linux or the FS(-driver) ? AFAICS it must be the FS.
Does it work with ext2- or ext3-driven volume, or even a more traditional
unix FS ?

You know, my problem is still the difference between the impression I got
from Vaclavs postings (IIRC "traditional unix/FS dont support holes") and
the unbeatable argument from CF "traditionally unix programs can expect
filesystems that automatically maintain holes".

E.g. my guess still is that the program (movie or CD burning ?) which
made Vaclav to leverage NTFS-sparse-files into cygwin never worked
performant on traditional unix/FS (unless it had not access to other
peoples unzeroed clusters like 9x/Me), so cygwin_sparse would not be
a feature making cygwin a good unix environment but instead a feature
(sometimes!) making it far better than a typical traditional unix


Unsubscribe info:
Problem reports:

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