update OS -> corrupt VDI?

[MountainTrails]

YES! I have the file and a lot more. First thing I did was back it up in a couple places.

I documented the process for anyone else behind me, and I will come back later today and get it down in a post.

But for now, I just wanted to share the success. Thanks again. Maybe I can buy you a good meal when I'm in your area (I travel some for work).

[mpack]

Congratulations. I would not have expected a recently modified file to be located inside the first 1GB of a 25GB drive. Your chance of success was IMHO way less then 5%, but I'm glad you beat the odds.

[MountainTrails]

Okay, the sequence that got me my files back. (By the way, all this was done on a copy of the original.)

I applied the patch to overwrite the first 106496 bytes of the bad VDI, as previously documented using dd.
Tried to start the virtual machine. No.

I then attached the VDI to a running virtual machine. It happened to be Windows XP. No shit. Most of my virtual machines are various flavors of Linux, BSD, Solaris, even Plan 9. Windows options were limited.

I started the virtual machine and the OS detected a disk problem. Want to try to fix? Sure. Nothing to lose. To make a long story short, it ran a long while giving me updates. Things started looking up when I started seeing "Recovering orphaned file x into directory file y" messages. Yay. I finished after a number of hours.

But when the virtual machine finishing fixing detected problems and tried to boot the OS, it started a loop of bluescreening and restarting so quickly I couldn't read the problem off the screen. Stop the machine. Okay, no good. Let's go get those files back.

cd to the directory holding the copied VDI file (win.vdi)

NOTE: a simple "modprobe nbd" resulted in a "special device does not exist" message from qemu-nbd. So instead:

modprobe nbd max_part=15
qemu-nbd -c /dev/nbd0 win.vdi
fdisk /dev/nbd0 (to find the right partition/device name: just p to print the partition table to the screen and then q for quit)
mount /dev/nbd0p2 /mnt/recovered_vbox/

And that was it. The recovered files were sitting in /mnt/recovered_vbox/. I grabbed the file I cared about first, then went back and copied the entire filetree off.

[mpack]

I grabbed the file I cared about first, then went back and copied the entire filetree off.

I wonder if you aren't fooling yourself. I told you a couple of posts back that the filesystem was likely to be almost intact. Also you know that I patched the VDI header to stop you getting errors that would prevent you attaching the VDI to a VM.

So, naturally if the filesystem is intact you might see a whole mess of filenames listed (i.e. directory information still exists), and apparantly be able to copy them off. But their contents would mostly be 0 bytes, because there is no actual data behind the filenames. On NTFS this would be especially so with larger files - very small files are stored in the directory entry!

Hopefully the file you actually wanted is intact, I assume you checked that. But the other files needs to be checked too, as and when you need them. You can't assume that just because you got no errors when copying then that means the file is ok.

[cyman1964uk]

mpack,

I have carried out your procedure using Frhed and attach my .rar file to this post. Please would you take a look at it and let mw know what can be done in terms of fixing/recovering data from my .vdi file?

[mpack]

I'm not inclined to do anything until you tell me what the problem is, or why you think you have one. I suggest that you start a new topic for it, since the OP's discussion is unique to him. And please provide the other information I asked the OP for, i.e. file size in bytes.