On 26/05/10 02:01, Pádraig Brady wrote:
> 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

Attached.

>> 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?

With multi-precision expr now in fedora one could simplify to:

truncate -s$(expr $(stat --format %s file) '*' 110 / 100) file

I'm still not convinced it's worth bringing % calculations within truncate.

cheers,
Pádraig.