bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature Request: include sparse - Produce one or more sparse files f


From: Eric Blake
Subject: Re: Feature Request: include sparse - Produce one or more sparse files from an input stream. - for repacking files and streams
Date: Fri, 04 Dec 2009 06:42:56 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to address@hidden on 12/4/2009 2:36 AM:
> I originally wrote this because I seemed to see a lack of any similar
> program on 3 different distributions I use.

Thanks for the proposal.  Unfortunately, while you did a great job of
describing that your code exists, you did a poor job of describing what
task you need accomplished, and why your code is the only thing that
appears to be able to achieve your end goal.

Have you tried truncate(1), provided by default in coreutils 7.0 or newer?
 There has been discussion on this list about making GNU truncate slightly
more powerful (as in copying fallocate(1) behavior of some other
implementations).  But it seems like truncate would be the perfect program
to extend for dealing with sparse files, rather than writing a new one.
(Hmm, on looking at your source, your comment mentions that you used
truncate(1) to create the sparse files that the rest of your unit tests
then manipulate).

Furthermore, cp(1) already knows how to deal with sparse files; the
- --sparse option can be used to expand an existing sparse file or compress
a file with explicit 0s into a sparse file, when copying into a new file.
 Tuning the size of the sparseness has generally never been requested
before - you either want a file as sparse as possible, or not sparse at all.

> Thus, I submit my code and this request, please consider adding it to the 
> coreutils package.

Unfortunately, it's not quite that simple.  We need more convincing why a
new program is better than existing capability, and we would also need
copyright assignment to FSF.  Also, your example does not follow the same
coding conventions as the rest of coreutils, and needs a NEWS blurb and
info documentation.  If you really want it in coreutils, I'd rewrite it as
a patch on top of coreutils.git rather than an independent repository.
Personally, I didn't even spend much time reviewing it for technical
merit, because it was such a different style and I don't want to be the
one rewriting it to fit coreutils' style.  In other words, if you want a
more thorough review, then making your contribution fit the existing mold
will get you a lot further in having people willing to read it.

> As I am unsure if this list allows large posts / attachments I shall instead 
> provide the current git repository: 

The git repository is nice, but the list does accept attachments up to
100k (compressing larger attachments is fine), so it is customary to post
the patch in addition to a link to a repository.  Even listing the --help
summary of your program would have at least given some better discussion
points on your proposed interface (hmm; you don't even have --help
support, just -h which mixes --version and --help into the same output):

>  fprintf(f_err,
> "sparse version 0.0.1\tCopyright (C) 2009\tMichael J Evans\n"
> "%s\n"
> "Usage: %s [OPTION]... [FILE]...\n"
> "Sparsely copy input to one or more output files.\n\n"
> "\t-p\tcoPy out of the first file instead of stdin.\n"
> "\t-i\tInput block max size\n"
> "\t-o\tOutput block max size (this is how large a string of zeros skip 
> writing)\n"
> "\t-t\tTruncate trailing zero pad (if any, for last file only)\n"
> "\t-l\ttake the very first option after the flag set as a comma seperated 
> List of filesizes, the last size being reused for all subsiquent files 
> (except stdout)\n\n"
> , gnu, *(argv - 1));

If nothing else, your calling convention looks different than cp.  For
example, where 'cp A B C' copies A and B into directory C, it appears that
your proposed 'sparse A B C' copies A into sparse files B and C.  I find
that confusing; it may be better to model your command line syntax after
cp, since cp already handles sparse files.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksZEd8ACgkQ84KuGfSFAYDM0wCg02wnqNZZ5eAIjNfE4ASfLF6M
n0UAnRCzfcoeL1A0LLbyWy/CmBwGhROV
=y/Y4
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]