CloneVDI tool - Discussion & Support

[mpack]

You should ask the question about desktop icons in another topic, but the most obvious cause IMO is that you're looking at the desktop for a different user account (*). If the VM got as far as that then clearly the disk was successfully cloned, as failure to do that right results in a VM that won't boot, not in a VM with a few missing graphics.

(*) Another possibility occurs that you imaged a newfangled OneDrive based desktop, and don't have OneDrive enabled on the VM. In general if it's a business PC then the IT people can locate the desktop contents on a server somewhere, giving you the same desktop on multiple devices. I didn't think of this right away because I instinctively avoid what I see as unnecessary complexity concerning my data.

I won't discuss these issues any further in this topic, since they have nothing to do with CloneVDI.

[martin123]

Thank You. Have a great day.

[necros2014]

Can possibly new version email notification be implemented?

[mpack]

Since there's no user registration that's not really a practical proposition. Nor is there money to pay for a server to host update checks.

And in any case it's a simple tool that doesn't need these things IMO. I don't expect Phillips to send me an email notification every time they tweak the design of their cross head screwdriver: if I have a problem with my current screwdriver I'll go looking myself!

[davmur]

Trying CloneVDI to recover corrupt VDI.
Host was windows 7 - Guest was Linux Mint. PC Motherboard caused total crash. Replaced PC and reinstalled Windows and Oracle.
Selecting VDI file to clone, Shows Validation result: "Source file is not a recognized VDI file format.
Have tried on original and copied VDI file.
Have not been able to find help on this.

[mpack]

If the file is a repairable VDI then a repair button will appear. If it's not really a VDI, or the VDI is not repairable then that's game over.

I have this conversation once every couple of years, but only in the context of someone who has recovered a VDI using an undelete tool. If that is you then I'm afraid you've been had: those undelete tools are snake oil, and the only thing correct about the file is its name and size (i.e. the stuff that can be found in the directory entry). The file content is 100% garbage, and there is 0% chance of making any sense of it.

[davmur]

If the file is a repairable VDI then a repair button will appear. If it's not really a VDI, or the VDI is not repairable then that's game over.

The repair button does appear, but get the attached message.
I selected Yes and it went through the whole process and then got 2nd attachment. Recovered file was 2KB but disappeared when I clicked OK.
I did not have to use an undelete tool as the file is one its own HDD.

[mpack]

"OS error 0" means that the file is truncated - too short. CloneVDI can't fix that - it can only fix header errors.

[davmur]

"OS error 0" means that the file is truncated - too short. CloneVDI can't fix that - it can only fix header errors.

does this mean there is no chance of even retrieving one folder. It is only one that really matters.

[mpack]

Hmm. If your data really mattered then you'd have a backup.

We can fall back on older methods for analysis. Please use a hex editor to save off the first 2101248 bytes of the corrupted VDI (that's 2MB+4KB) to a binary file. Zip that file and attach the zip here. I will also require to know the current VDI file size, in bytes.

And just to be clear: it's obvious that the corruption extends into the disk image, perhaps the block map too. There's no way to know how much of the filesystem is usable, so while we may get to the point where VirtualBox accepts the VDI, there's no way to know what if any of the data will be recoverable.

[davmur]

The first part of the file as requested comes to 2052KB and when Zipped is 287KB. The file upload only allows 256KB??

Now downloaded 7-zip.

File attached as requested.
Original size is 219043332096

I understand this may still be unsuccessful.
Thank you

[mpack]

Was this a fixed size drive? The blockmap shows a purely linear block order, with no unallocated or zero blocks. It also shows a logical capacity (should match actual image file size, since it's fixed size) of 209427MB. The VDI file size should therefore be that plus 2MB for the header and blockmap, i.e. 209429MB, or 219602223104 bytes. The file size you quote seems to be short by 533MB.

The good news is that a fix should be relatively easy. You need to use that hex editor again to discard the leading 2MB from the file, then add packing on the end of the file to make it 209427MB exactly (in all this, 1MB = 1048576 bytes = 1024*1024). Save the image as a ".raw" file, then use "VBoxManage convertfromraw" to turn the raw image back into a VDI. Of course this will give it new UUIDs.

The CloneVDI repair function isn't designed to deal with truncated VDIs, as already mentioned. It exclusively fixes bad headers.

p.s. Zipping would normally make your snippet file small enough to attach, but your blockmap was unexpectedly "busy" (because it's from a fixed size VDI) and so doesn't compress very well as a zip. It's interesting to see how much better 7z performs with the same data.

p.p.s. When I say "a fix should be easy", I mean that in the same sense I meant it before: that it should be easy to make VirtualBox happy with the disk image. But whether the disk image contains the data you care about there's no way to know - and we're still missing about half a gig. I would be hopeful however that that's where Mint would normally have a swap partition, and that ought to be fully discardable.

p.p.p.s. You might be thanking your lucky stars that you went for a fixed size drive, make recovery possible, right? But the flip side of that coin is that 200GB files are usually a chore to make backups of. A backed up dynamic VDI would have made recovery way easier still.

[davmur]

The good news is that a fix should be relatively easy. You need to use that hex editor again to discard the leading 2MB from the file, then add packing on the end of the file to make it 209427MB exactly (in all this, 1MB = 1048576 bytes = 1024*1024). Save the image as a ".raw" file, then use "VBoxManage convertfromraw" to turn the raw image back into a VDI. Of course this will give it new UUIDs.

Please would you assist with more details/instructions on how to do this, I am not very familiar with editing with a hex editor. I have HxD. I tried the frhed that you have mentioned in some posts, but it cannot open the large VDI.
Thank you

[mpack]

Sorry, I have no suggestions on tools to do that job, as I've never needed to find one ((*) actually I found a potential tool - see note). If I had this problem I would just knock up a little code (not even a complete app) to copy selected 1MB blocks from one file to another. You need to skip the first two blocks, copy all remaining blocks, then pad the "output file to 209427 blocks using zero blocks. Then rename the output file to <something>.raw and it will be ready for conversion to a dynamic VDI.

I'm sure that a more capable (than FrHed) binary editing tool must exist. I imagine it would also be possible to do this using Python, or maybe some batch/script language and some variation of 'dd'.

[Edit*] It just occurred to me that all you need to find are file split and file join tools. Ideally you need to find a file split tool that lets you pick where the split happens. You currently have a file which is 208896MB, you want to end up with a file which is 209427MB after removing the 2MB header. So, you do this:

1. Split your file into two pieces which I will call A(2 MB), and BC(208894 MB). Discard the A piece.
2. Split your BC file into two pieces which I will call B(208361 MB), and C(533 MB).
3. Create a copy of piece C, which I will call D.
4. Now join B+C+D. This gives you a 209427 MB raw disk image, ready to be converted to dynamic VDI.

I have found a free file splitting tool that allows you to set the size of each piece, it seems to be legit: I tested the split function but not the "unite" function.

[VM-F4n]

Can clonevdi handle missing snapshots to create a ned vdi base file?
https://www.treshna.com/rebuilding-virt ... snapshots/