bug-coreutils
[Top][All Lists]
Advanced

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

bug#6268: Suggestion: truncate should allow -r and -s options together


From: Pádraig Brady
Subject: bug#6268: Suggestion: truncate should allow -r and -s options together
Date: Wed, 26 May 2010 02:01:25 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

On 25/05/10 15:32, Richard W.M. Jones wrote:
> The manpage for truncate says:
> 
>   Note that the -r and -s options are mutually exclusive.
> 
> and indeed you cannot have both:
> 
>   $ truncate -r /tmp/ref -s +10M /tmp/new
>   truncate: you must specify one of `--size' or `--reference'
> 
> We suggest using the 'truncate' command in the 'virt-resize'
> documentation[1].  We want users to create a file which is the size of
> an existing file + some extra amount.  Naturally this would be:
> 
>   truncate -r old-disk.img -s +1G new-disk.img
> 
> but this does not work and we have to suggest that users use two
> separate 'truncate' commands[2].

That seems like a worthwhile change.
I.E. allow relative --size with -r.
I'll cook up a patch in the morning.

> Related to this feature request, it would be nice if you could suffix
> a size with a % sign to indicate that you want to increase a file by a
> certain percentage of the old or reference size, eg:
> 
>   truncate -r old-disk.img -s +10% new-disk.img
> 
>   truncate -r old-disk.img -s 110% new-disk.img

I'm a little less enthusiastic about the need for that.
Given how awkward it is to achieve then I might do it
(as a separate patch). Here's how you'd might do it
handling overflow currently:

truncate -s$(echo "$(stat --format %s file) * 1.1" | bc | cut -d. -f1) file

I guess it would be OK to truncate the result
rather than round to nearest?

cheers,
Pádraig.





reply via email to

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