libyal / libvmdk

Library and tools to access the VMware Virtual Disk (VMDK) format

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Handle renamed single monolithic sparse images

uckelman opened this issue · comments

  1. Create a monolithicSparse type VMDK named foo.vmdk.
  2. Rename it to bar.vmdk.
  3. Try opening bar.vmdk with libvmdk.
  4. 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.