aboutsummaryrefslogtreecommitdiff
path: root/stubs
diff options
context:
space:
mode:
authorMax Reitz <mreitz@redhat.com>2018-05-09 20:20:01 +0200
committerMax Reitz <mreitz@redhat.com>2018-06-11 16:18:45 +0200
commitd16699b64671466b42079c45b89127aeea1ca565 (patch)
treeca60dd12a36c9f6bd130a302b8b5aecbedf5bff7 /stubs
parente4ca4e981a0a389d6af5dc5d8b5fbdd1a05276a0 (diff)
downloadqemu-d16699b64671466b42079c45b89127aeea1ca565.zip
qemu-d16699b64671466b42079c45b89127aeea1ca565.tar.gz
qemu-d16699b64671466b42079c45b89127aeea1ca565.tar.bz2
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 'stubs')
0 files changed, 0 insertions, 0 deletions