On 04/11/2014 08:46 PM, John Ferlan wrote:
On 04/11/2014 12:21 AM, Eric Blake wrote:
Thanks to the testsuite, I feel quite confident that this rewrite still gives the same results for all cases except for one, and I can make the argument that _that_ case was a pre-existing bug. When looking up relative names, the lookup is supposed to be pegged to the directory that contains the parent qcow2 file.
* src/util/virstoragefile.c (virStorageFileChainLookup): Depend on new rather than old fields. * tests/virstoragetest.c (mymain): Adjust test to match fix.
Signed-off-by: Eric Blake <eblake@redhat.com> --- src/util/virstoragefile.c | 49 +++++++++++++++++++---------------------------- tests/virstoragetest.c | 3 +-- 2 files changed, 21 insertions(+), 31 deletions(-)
ACK
Although I'll admit I don't know enough about all the backing chain code to fully understand the "pre-existing" bug comment.
This is the comment I added earlier in the series explaining the pre-existing bug: /* FIXME: 21 is questionable, since there is no 'sub/qcow2' and * since relative backing files should be looked up in the context * of the directory containing the parent. */ (oops, I already removed the comment in 4/6, even though the bug wasn't addressed until 5/6). I'll describe it in more detail in the commit message.
I suppose the only odd part I found was the comparison < VIR_STORAGE_TYPE_DIR - leaving currently DIR, NETWORK, and VOLUME out of the comparison. My thoughts went to what if something new comes along and what on earth was being compared beforehand...
I think I'll rewrite that to use explicit comparison against VIR_STORAGE_TYPE_FILE and VIR_STORAGE_TYPE_BLOCK instead. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org