Handle renamed single monolithic sparse images
uckelman opened this issue · comments
- Create a
monolithicSparse
type VMDK namedfoo.vmdk
. - Rename it to
bar.vmdk
. - Try opening
bar.vmdk
with libvmdk. - Get this error:
error: Error opening image file (src/vmdk.cpp:104: libvmdk_handle_open_extent_data_files: unable to read grain table.)
Had an error opening the evidence file
** seg[0] = /home/juckelman/projects/test-files/bar.vmdk
The cause is easy to see in the embedded descriptor file:
# Extent description
RW 3584001 SPARSE "foo.vmkd"
libvmdk is looking for the extents in foo.vmdk
, but not finding it because the file has been renamed.
Renamed monolithic images are a fairly common thing to encounter. Some other tools, such as VirtualBox, are able to open renamed monolithicSparse
images. I've tried to determine what behavior is mandated by the spec---specifically:
- Is it permissible for a
monolithicSparse
image to have an extent which is not in the same file as the descriptor?
The Virtual Disk Format 1.1 spec says (p. 18):
An embedded disk descriptor can be used only when the first extent of a link is sparse
The Virtual Disk Format 5.0 spec (p. 3) says:
monolithicSparse - single sparse extent with embedded descriptor file
Based on this, it appears that the correct behavior for monolithicSparse
images is to ignore the filename given in the descriptor for the single extent and instead use for the extent filename the filename of the file containing the descriptor.
Does this fit your understanding of things? If so, I'll work up a patch to make libvmdk behave this way.
Does this fit your understanding of things?
Yes, from https://github.com/libyal/libvmdk/blob/master/ChangeLog#L15
* if there is a single filename in the disk database and the current file is
not a descriptor-only file assume the current file is the right one even if
the names don't match
In this regard we can adopt the most flexible behavior.
I'd noted this but have not implemented it yet.
If so, I'll work up a patch to make libvmdk behave this way.
That would be helpful, thanks.
Fixed in PR #8.
PR does not fix the issue correctly:
- does not account for non UTF-8 narrow system strings
- does not account for wide system strings
- it does not preserve the extent file name for usage in vmdkinfo
Hence I've started making some changes:
d494172
Not finished yet, but I'll close the PR
The same happens not only for "monolithic sparse" format but also for e.g. "stream optimized". Is the issue fixed by now?
@welkomier yes, very simple, just rename the file back to its original name.