Re: [Qemu-block] [PATCH v2 1/2] qemu-img: Resolve relative backing paths in rebase

[Max Reitz]

On 2018-05-09 20:51, Eric Blake wrote:
> On 05/09/2018 01:20 PM, Max Reitz wrote:
>> Currently, rebase interprets a relative path for the new backing image
>> as follows:
>> (1) Open the new backing image with the given relative path (thus
>> relative to
>>      qemu-img's working directory).
>> (2) Write it directly into the overlay's backing path field (thus
>>      relative to the overlay).
>>
>> If the overlay is not in qemu-img's working directory, both will be
>> different interpretations, which may either lead to an error somewhere
>> (either rebase fails because it cannot open the new backing image, or
>>   your overlay becomes unusable because its backing path does not point
>>   to a file), or, even worse, it may result in your rebase being
>> performed for a different backing file than what your overlay will point
> 
> Interesting indentation in this paragraph. A maintainer could tweak it.

Well, it was meant this way (because of the opening paranthesis), but I
could out-dent it.

Max

>> to after the rebase.
>>
>> Fix this by interpreting the target backing path as relative to the
>> overlay, like qemu-img does everywhere else.
>>
>> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1569835
>> Cc: address@hidden
>> Signed-off-by: Max Reitz <address@hidden>
>> ---
>>   qemu-img.c | 23 ++++++++++++++++++++++-
>>   1 file changed, 22 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Eric Blake <address@hidden>
>

signature.asc
Description: OpenPGP digital signature