Giuseppe Scrivano wrote:
> Hello,
>
> Pádraig Brady <P@xxxxxxxxxxxxxx> writes:
>
>> Tilman Schmidt wrote:
...
>>> Why not make it, in the best Unix tradition, a single
>>> executable whose action depends on the name it is run as?
>> Hmm. Good idea.
>> There is precedent for that already in coreutils.
>
> What do you think about having two separate executables? Considering
> fallocate and truncate will share almost all code, these differences can
> be separed at compilation-time. It seems that the same approach is
> already used by md5sum and shaXXXsum.
I'm curious - how much code will be shared, really?
in terms of functionality, truncate currently has:
-c, --no-create
do not create any files
-o, --io-blocks
Treat SIZE as number of IO blocks instead of bytes
-r, --reference=FILE
use this FILE’s size
-s, --size=SIZE
use this SIZE
--help display this help and exit
--version
output version information and exit
the_util_previously_known_as_fallocate would have something like:
-c, --no-create
do not create any files
-o, --offset=OFFSET
start allocation at this OFFSET (0 default)
-l, --length=LENGTH
allocate this LENGTH starting at OFFSET (or 0)
-n, --no-size-update
do not change i_size (allow blocks past EOF)
--help display this help and exit
--version
output version information and exit
I suppose -c might be shared between the two; it's a question of O_CREAT
or not, right. But that's just a line or two.
the k/m/g/t/p/e parsing would be shared, but hopefully that's in a
library somewhere?
the allocation tool, if done portably, would have a whole whack of
configure-time options, I'd expect, based on which OS it's trying to
allocate on, and what interface the OS provides.
AFAIK, truncate(2) is truncate(2) just about everywhere.
If it really makes sense to share, fine, but I'm surprised that it'd be
a lot of common code. Maybe after it gets written it'd be more obvious.
Thanks,
-Eric
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
