/mkfile/02-mkfile-sparse: test for creating of sparse file
tests/mkfile/03-mkfile-wrong-behavior: tests for incorrect use
Signed-off-by: Matej Cepl
---
README-prereq |6 +-
doc/coreutils.texi| 50 ++-
man/mkfile.x |6
Hi,
I wanted to write this utility which exists on other Unices for
some time, but with introduction of posix_fallocate this actually
seems make sense now.
Eagerly waiting for comments and critcism -- this is my first
serious program in C which I make public, so I expect a lot of
both ;-).
Best
On 2009-02-06, 23:37 GMT, Pádraig Brady wrote:
> Rather than creating a new utility, prehaps a --preallocate
> option to the existing truncate utility would be better?
> Especially considering you added a --sparse option to mkfile
> which does much the same thing (although not allowing shrinking?).
On 2009-02-08, 00:01 GMT, Pádraig Brady wrote:
> It wasn't called after the system call. It was called after the
> function it was providing. mkfile isn't the best name either BTW.
> Also the existing `truncate` command in freebsd which
> swayed the choice of name.
OK, so what do you suggest to do
-mkfile: test mkfile(8)
Signed-off-by: Matej Cepl
---
doc/coreutils.texi|9
man/mkfile.8.xml | 94 +
src/mkfile| 81 +++
src/truncate.c| 48
On 2009-02-27, 14:48 GMT, Pádraig Brady wrote:
> Thanks for following this up Matej.
> Some very quick comments below. Will review more thoroughly when I've time.
Should I send a patch-to-patch or a new one?
> I would mention that the main reason for this call is
> to ensure blocks are contiguous
d)
* src/truncate.c: rename the option from --fallocate to --allocate
nobody is interested in the implementation of the option.
Signed-off-by: Matej Cepl
---
configure.ac |1 +
doc/coreutils.texi |8 +++--
man/mkfile.8.xml | 94 -
OK, another turn around of fixes. This is just the last patch,
whole branch is available at
http://github.com/mcepl/coreutils/tree/truncate-fallocate (repo
URL is git://github.com/mcepl/coreutils.git).
One note about this patch is that I have unsuccesfully tried to
use @bindir@ to have the scrip
On 2009-02-28, 13:25 GMT, Eric Blake wrote:
> Meanwhile, you probably need to clear up your copyright
> assignment for both coreutils and gnulib.
I will work on the rest of your requirements later (it will take
some time), but to this one -- isn't there an automatic
assignement for Red Hat empl
On 2009-04-03, 10:25 GMT, Pádraig Brady wrote:
> I noticed another thread with more info about fallocate:
> https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html
>
> That got me thinking about whether we should use fallocate()
> if available in cp etc. so ext4 etc. can allocate
Pádraig Brady, Tue, 02 Jun 2009 22:49:31 +0100:
> I wasn't referring to the update to the automake info, I was warning
> about assuming one is using Fedora 11.
Yeah, I was trying not-to-promote EOSed Fedora 8. But we should probably
not mention any distro version, just required versions of packag
Eric Blake, Wed, 03 Jun 2009 06:58:02 -0700:
>> > I'll update the automake info...
>>
>> I just pushed this:
>> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=ba6e08c
>
> That's still misleading. Automake 1.11 is a stable release, and distros
> are starting to pick it up as such
Eric Sandeen, Sun, 14 Jun 2009 23:38:34 -0500:
> I'd personally rather see a separate, dedicated fallocate tool ... but
> maybe that's just me. You might run it by the fsdevel-list, or maybe
> I've bike-shedded enough already. :)
I still have in my patch and I plan to push into coreutils (if pos
Pádraig Brady, Sat, 13 Jun 2009 01:19:36 +0100:
> I was thinking that truncate --allocate would call posix_fallocate()
> which guarantees that the file is allocated even if the filesystem does
> not support fallocate(). I.E. we would need to add a posix_fallocate()
> gnulib module that adds the fun
Pádraig Brady, Mon, 15 Jun 2009 13:48:47 +0100:
> http://www.pixelbeat.org/patches/gnulib-fallocate.diff
Could I get a branch of it? I hate following patches...
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo
Richard Guy Briggs, Fri, 10 Jul 2009 07:53:21 -0400:
> The standard for documentation has been man for longer than that... It
> should be complete.
You are right of course, and GNU's insistence on stupid info format is
terrible (yes, I hugely prefer manpages over info, even for massive
manpages
16 matches
Mail list logo