3

I have some automated test (using CUnit) which require a "disk-image"-file (raw copy of a disk) to be "mounted" in windows and explored. I have previously used a tool/library called "FileDisk-17" , but this doesn't seem to work on my Windows 7 (64bit).

Update I should point out, that changing the image-format (to say VHD) is not at option.

Any suggestions as to other (perhaps better supported) tools or libraries for mouting the file? The project is coded in ANSI C and compiled using MinGW.

Best regards!

Søren

S.C. Madsen
  • 5,100
  • 5
  • 32
  • 50
  • Is it good enough to convert it to VHD then convert it back again afterwards? `qemu` can convert both ways. – Ben Mar 17 '11 at 11:22

2 Answers2

4

Edit: Searching Bing for +filedisk 64 brings up a 64bit build of FileDisk, the utility you refer to:

http://www.winimage.com/misc/filedisk64.htm

And FileDisk-15 signed for 64bit here:

http://www.acc.umu.se/~bosse/

I can't vouch for it as I have never used it and am not familiar with the author.

Alternatively:

If you have a VHD, you can mount that in windows easily:

http://technet.microsoft.com/en-us/library/cc708295(WS.10).aspx

See also:

http://www.petri.co.il/mounting-vhd-files-with-vhdmount.htm

Since you have a raw DD image not a VHD, you will need to convert it first:

http://www.bebits.com/app/4554

Or qemu-img.exe can also do this:

qemu-img.exe convert -f raw rawdisk.img -O vpc rawdisk.vhd

Alternatively, you can create an empty VHD, and use DD to copy the raw image to the VHD, by opening the VHD as a raw device.

Ben
  • 34,935
  • 6
  • 74
  • 113
  • Hi Ben, I should have been more precise: I need to keep the image-format unchanged, as the code I'm testing manipulates the image (which I then need to verify using the Windows filesystem). – S.C. Madsen Mar 17 '11 at 11:06
  • Isn't it good enough to convert it to VHD then convert it back again afterwards? `qemu` can convert both ways. – Ben Mar 17 '11 at 11:20
  • I would rather mount the image directly. I've had this working on WinXP with no problems in the past. – S.C. Madsen Mar 17 '11 at 11:42
  • +1 Nice one for finding an alternate version of filedisk, marking as solution. Thanks! – S.C. Madsen Mar 17 '11 at 12:47
2

I faced this problem recently and found ImDisk to be an extremely nice solution:

  • Free, with source available and a very flexible open source license
  • Trivial setup (I have seen filedisk64 (in the accepted answer) described as having a "technical" setup)
  • Straightforward GUI and command-line access
  • Worked on Windows 7 64-bit
  • Seems to happily mount any kind of filesystem recognised by Windows (in my case, FAT16)
  • Works with files containing
    • Raw partitions
    • Entire raw disks (i.e. including the MBR and one or more partitions; which partition to mount can be selected)
    • VHD files (which it turns out are just raw partitions or disks with a 512-byte footer appended!)
  • Also can create RAM drives -- either initially empty or based on an existing disk image! (Very neat I must say!)

I did encounter minor issues trying to unmount drives. I was unable to unmount a drive from the GUI right-click context menu as the drive appeared to be "in use" by the explorer.exe process. Closing the Explorer window and using imdisk -d -m X: also didn't work; however imdisk -D -m X: (-D "forces" an unmount, whatever that means) did. This worked even if the drive was visible in an open Explorer window, without appearing to create any problems. However even after the drive appeared to have fully unmounted, an imdisk -l to list all available devices would still report that \Device\ImDisk0 exists, and if you remount the drive later, both that and \Device\ImDisk1 will appear in the output of imdisk -l (and so on with more unmount/remount cycles). This didn't create any problems with actually using the mounted drive when I tried a few unmount/remount cycles, though it theoretically might if you perform this many times between reboots.

ImDisk was invaluable for transferring the contents of a 1.5Gb disk drive with one FAT16 DOS partition from an ancient 486 machine.

j_random_hacker
  • 50,331
  • 10
  • 105
  • 169