diff options
author | Max Reitz <mreitz@redhat.com> | 2018-05-09 20:20:01 +0200 |
---|---|---|
committer | Max Reitz <mreitz@redhat.com> | 2018-06-11 16:18:45 +0200 |
commit | d16699b64671466b42079c45b89127aeea1ca565 (patch) | |
tree | ca60dd12a36c9f6bd130a302b8b5aecbedf5bff7 /tests/qemu-iotests/024.out | |
parent | e4ca4e981a0a389d6af5dc5d8b5fbdd1a05276a0 (diff) |
qemu-img: Resolve relative backing paths in rebase
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 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: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180509182002.8044-2-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Diffstat (limited to 'tests/qemu-iotests/024.out')
0 files changed, 0 insertions, 0 deletions