22 replies to this topic

[bartman2589]

I have been having problems saving disk images with ImDisk, specifically when I try to 'save disk contents as image file' from the context menu or even when I try to save the image file from the control panel gui, no matter what I do I get a disk image that reports as the correct size however when I try to mount it then browse to it in explorer I'm told the disk is not formatted and am subsequently asked if I want to format it. I have been able to add files to a freshly created disk image after formatting it however, and if I simply unmount the image then subsequent mounts show the files I added, however all attempts to save the image from the control panel gui or from the context menu option result in a blank image file, I have even tried using other image file making programs such as Roadkill's DiskImage utility and yet I still get a blank image. I am specifically trying to use ImDisk to make a backup of the contents of one of my USB Flash Drive that I use when I go work on other people's computers, the idea being that if I get a virus from their computer then I can just restore the image file I created back to the drive using a diskcopy utility. If anyone can help me figure out what's going on I'd greatly appreciate it. TIA for any help.

Thanks,
bartman2589

BTW, I'm using ImDisk on Windows XP Pro w/SP3 with 2.5 Gig RAM and a 300 Gig Maxtor SATA HD.

[Wonko the Sane]

Imdisk is not a tool for imaging a disk drive.

It ignores the partitioning and "connects" just to the filesystem (or if you prefer it sees each and any partition on a disk as a super-floppy).

This is by design.

You can use any of the disk cloning/imaging softwares available, a rather complete list is here:
http://www.911cd.net...showtopic=16534
more here:
http://www.msfn.org/...re-t100299.html

To mount the RAW image you can use VDK
http://chitchat.at.i...vmware/vdk.html
optionally using a pseudo GUI:
http://home.graffiti...ts/VDM/vdm.html
http://vmxbuilder.com/vdk-gui/


or MS own VSS drivers:
http://www.boot-land...?...ic=6492&hl=

To force a given geometry with VDK you may need use of a .pln descriptor:
http://www.forensicf...m...opic&t=1489
http://www.forensicf...m...sc&start=42

More drivers listed:
http://www.boot-land...;showtopic=1507

Wonko

[bartman2589]

"Imdisk is not a tool for imaging a disk drive."

Then why even have an option for saving the CONTENTS of a drive as an image file if it isn't going to work??? And why have the 'Save...' option present in the control panel gui if it doesn't save the actual contents of the current virtual disk??

As I stated I even tried using another program to make a raw image file of my USB Drive and then attempted to load that image in ImDisk but for some reason it doesn't load properly, my goal isn't just to backup my drive it's also to allow me to access the utilities on the drive without having to go fishing around for the actual drive itself (which may not be feasible if I say for example left it at someones house, or left it in a car or something like that), my point is that there seems to be a fundamental flaw with ImDisk's ability to load and save it's own image files (files which it's own 'save disk contents as image file' context menu item and control panel gui 'Save...' options should theoretically produce USABLE image files but which however actually fail completely to produce a usable image file), I did not only have these problems with my USB Flash Drive but also with a 2.5" laptop hard drive attached through a USB adapter that was designed to make the drive portable, whenever I attempted to use the 'save disk contents as image file' context menu option I ALWAYS ended up with an image file that apparently did not actually contain the contents of the drive that the image was supposedly made from!!!!!

You also say "It ignores the partitioning and "connects" just to the filesystem (or if you prefer it sees each and any partition on a disk as a super-floppy).
"

If this was the case then unless I'm missing something it shouldn't have had any problems loading the raw image file I created using DiskImage since the drive wasn't partitioned at all. Yet each and every time I mounted this image it failed to allow me to access the files in it, the drive was formatted with Fat32 (which I know XP fully supports), so that leaves me with only being able to trace the problem back to ImDisk. I should point out that I used WinImage (In trial mode) to attempt to load the image file and it appears to load fine to a point (I'm assuming that it has problems with very large image files of a certain type because shortly after displaying the list of files in the image WinImage crashes).

Again take note of the fact that the 'save disk contents as image file' context menu option wasn't working properly for me.

If this is all a problem with my system then I would ask someone to kindly aid me in tracking down where the problem lies as I have no idea where to start looking, however if it is actually a problem with ImDisk then I would urge the creator of ImDisk to fix the 'save disk contents as image file' context menu option so that it actually saves the actual contents of the disk (as the name of the context menu item suggests it should), instead of just creating an image file the same size as the disk that the context menu item was called from.

[Wonko the Sane]

"Imdisk is not a tool for imaging a disk drive."

Then why even have an option for saving the contents of a drive as an image file if it isn't going to work??? And why have the 'Save...' option present in the control panel gui if it doesn't save the actual contents of the current virtual disk??

Because a drive (or partition or volume or the whatever that gets a "drive letter") is not a disk drive.

Imdisk works with partitions.

A disk drive (or a USB stick partitioned as HDD) has the MBR and a number of hidden sectors that imdisk simply skips.

I.E.:
DISK DRIVE=MBR+Hidden Sectors+(one or more)Partition(s) (DRIVE(s))+possibly some unused sectors

I know it's confusing, it's the term "drive" commonly used as a synonym of "volume" or "partition" that creates most of the confusion with the the term hard disk drive.

A disk Drive is the "whole" a "drive" (or partition or volume) is a part of it.

If you try Winimage, it has basically (though through a different approach) the same behaviour, if you try opening with it a disk drive image, it will ask you to which partition you want to "connect":
http://www.winimage.com/winimage.htm

and before you ask, no, Winimage also is not fully featured/intended as a disk drive imaging solution.

Wonko

[bartman2589]

Because a drive (or partition or volume or the whatever that gets a "drive letter") is not a disk drive.

Imdisk works with partitions.

A disk drive (or a USB stick partitioned as HDD) has the MBR and a number of hidden sectors that imdisk simply skips.

I.E.:
DISK DRIVE=MBR+Hidden Sectors+(one or more)Partition(s) (DRIVE(s))+possibly some unused sectors

I know it's confusing, it's the term "drive" commonly used as a synonym of "volume" or "partition" that creates most of the confusion with the the term hard disk drive.

A disk Drive is the "whole" a "drive" (or partition or volume) is a part of it.

If you try Winimage, it has basically (though through a different approach) the same behaviour, if you try opening with it a disk drive image, it will ask you to which partition you want to "connect":
http://www.winimage.com/winimage.htm

and before you ask, no, Winimage also is not fully featured/intended as a disk drive imaging solution.

jaclaz

Ok some of what you said makes sense but I still have to ask why when I attempted to use 'save disk contents as disk image' context menu entry (which was provided by ImDisk when I installed it) did the resulting image not show up as having all of the information that the drive/partition it was imaged from had?

If in fact ImDisk truly does ignore the MBR and other items then shouldn't the image still have been able to be successfully mounted by ImDisk such that I should have had full access to all of the same information that was present on the actual drive/partition?? As near as I can tell in my case it's not ignoring the MBR and other stuff at all (I haven't tried using a hexeditor yet on the image file to see if it truly is blank or if the data is in fact there but ImDisk just can't access it). The whole point is that I made the images using ImDisk and then tried to mount them with ImDisk but ImDisk doesn't seem to recognize them as having data already present in them even though the drive the image was made from functioned fine.

[Wonko the Sane]

Well, that's probably another thing.

Imdisk can access BOTH a "super-floppy" or "partition" image (i.e. one which first sector is the bootsector) and a "whole drive" or "RAW" image (i.e. one which first sector is a MBR).
For the first, the image is mounted starting from 0.
For the second the image is mounted "skipping" a number of sectors (called "blocks" in IMDISK) corresponding to the "sectors before" in the LBA data of the Partition table.

If you try opening a partitioned image, with oldish versions of IMDISK without giving the correct offset, the mounted image will look unformatted/without filesystem as the image will be mounted starting with first sector.

Newish versions try to detect the partition table data and asks you to choose the offset to use to mount the partition if a multi partition is found or auto-calculate the number of .

When you "save" the image, what you save is not the whole image, but just the partition you have mounted, it is like you take a whole disk and strip from it anything before a single partition and anything after it, so the result is a "super-floppy" image.

I have not clear the procedure you are following that gives you the error.

Let's do a test.

Attached is a small (10 Mbyte HDD like image - complete with MBR and hidden sectors).

Just open the .zip, extract the image and try mounting it in IMDISK, you should be a ble to see in it a file in root, a folder in root and a file inside the folder.

Then save the image from IMDISK.

Compare the source and the saved image.

The source image is exactly 10,485,760 bytes, the saved image will be exactly 10,289,664 bytes.

You should be able to mount both with imdisk, first one with an offset of 63 blocks and second one with no offset.

If you copy the first 63 sectors from the original image to a file, say "MBR10Mb.bin" you can create a "new" "full image by adding these sectors to the image you have saved (say "saved10Mb.img") like in:

copy /b MBR10Mb.bin + saved10Mb.img FullMod10Mb.img

Which then it will be again "comparable" with the original one.



Wonko

Attached Files

•  10Mb.zip   13.33KB   485 downloads

[bartman2589]

Well, that's probably another thing.

Imdisk can access BOTH a "super-floppy" or "partition" image (i.e. one which first sector is the bootsector) and a "whole drive" or "RAW" image (i.e. one which first sector is a MBR).
For the first, the image is mounted starting from 0.
For the second the image is mounted "skipping" a number of sectors (called "blocks" in IMDISK) corresponding to the "sectors before" in the LBA data of the Partition table.

If you try opening a partitioned image, with oldish versions of IMDISK without giving the correct offset, the mounted image will look unformatted/without filesystem as the image will be mounted starting with first sector.

Newish versions try to detect the partition table data and asks you to choose the offset to use to mount the partition if a multi partition is found or auto-calculate the number of .

When you "save" the image, what you save is not the whole image, but just the partition you have mounted, it is like you take a whole disk and strip from it anything before a single partition and anything after it, so the result is a "super-floppy" image.

I have not clear the procedure you are following that gives you the error.

Let's do a test.

Attached is a small (10 Mbyte HDD like image - complete with MBR and hidden sectors).

Just open the .zip, extract the image and try mounting it in IMDISK, you should be a ble to see in it a file in root, a folder in root and a file inside the folder.

Then save the image from IMDISK.

Compare the source and the saved image.

The source image is exactly 10,485,760 bytes, the saved image will be exactly 10,289,664 bytes.

You should be able to mount both with imdisk, first one with an offset of 63 blocks and second one with no offset.

If you copy the first 63 sectors from the original image to a file, say "MBR10Mb.bin" you can create a "new" "full image by adding these sectors to the image you have saved (say "saved10Mb.img") like in:

copy /b MBR10Mb.bin + saved10Mb.img FullMod10Mb.img

Which then it will be again "comparable" with the original one.



Wonko

Ok, I think I see where the problem is now, it looks like it's related to the offset issue, If I understand correctly I should be able to strip it down so that I can leave the offset as 0 by trying to have ImDisk mount the image using 'Auto' for the type, and then once the image is mounted (assuming that I can see my data then) I should be able to use the context menu entry command to save a zero offset version that I shouldn't have any problem mounting, sound right? Do you know of any utilities I can use to 'automatically' find the offset in an image file so that I can therefore mount it in ImDisk (i.e. when ImDisk can't automatically find the offset itself, for instance if I created the Image with a different utility, or as in my current situation, the image was made from a 'non-standard' storage medium such as a Flash Drive or SD Card or similar media)? If I also understand correctly my usage of Flash media isn't 'technically' supported by ImDisk since that's one of the media types that's missing from list next to 'Auto', if this is so, do you know how I can calculate the offset I need to be able to mount images made from flash media (thumb drives, SD Cargs, Compact Flash Memory, etc...)? I would really like to be able to use a utility similar to ImDisk for making backup images of my flash media since to date I have seen very very few other options for backing up flash media (in a form where I would be able to access the backed up data, without having to use utilities like 7zip or other archiving programs), the benefit of being able to use a utility such as ImDisk would be that I could still successfully run any of the apps contained in the backup image in much the same manner as if I had run them straight from the original media (including full normal function of the launcher I use to automate launching the apps).


Thanks again,
bartman2589

[Wonko the Sane]

Well, you still appear to miss the initial idea.

• You need a tool to copy the INTEGRAL contents of your USB stick to an image file <- this is NOT what IMDISK is about
• You need a tool to mount the image file and modify it's contents <- this can be done by IMDISK
• You need a tool to save a copy of the (modified) image file <- this CANNOT be done by IMDISK as it will lose the initial "sectors", or, in the case of multiple partition only save one partition AND it will have "wrong" offset values in the PBR or bootsector.
• You need a tool to copy back the (modified) image file to the stick <- this CANNOT be done by IMDISK

This has nothng to do with the media type, it's simply that IMDISK has been designed as being filesystem (or partition, or volume) oriented as opposed to disk drive oriented.

• The "plainer" way is using a disk imaging software, since you need to modify the image often and you want to mount it to modify it without using a compression program, you should use a "forensic like image, it is very, very strange your report about Roadkil's DiskImage not working, it should work allright (as long as you DO NOT select for imaging a drive letter, but the actual PhysicalDrive), I already gave you a list of imaging programs, if you are allright with command line I recommend dsfo/dsfi.
• You can use IMDISK allright to modify the contents of the image, BUT you cannot SAVE a copy of it when mounted, as the copy will miss some parts, I suggested you a couple of drivers capable of mounting the whole PhysicalDrive, and a post where more known tools are listed.
• Once the image is mounted you can use the app in #1 above to take another image of the mounted PhysicalDrive.
• The same tools in point #1 will do.

Another approach, as long as you never modify the partition table of the stick, is to image, again with one of the apps #1 only the partition (or volume or filesystem or logical drive or "drive letter") and use IMDISK to modify it, BUT if you SAVE a copy of the IMDISK mounted image, you will need to correct the "wrong" data in the PBR before restoring the image to stick.

I hope now the matter is more clear.

Wonko

[bartman2589]

Well, you still appear to miss the initial idea.

• You need a tool to copy the INTEGRAL contents of your USB stick to an image file <- this is NOT what IMDISK is about
• You need a tool to mount the image file and modify it's contents <- this can be done by IMDISK
• You need a tool to save a copy of the (modified) image file <- this CANNOT be done by IMDISK as it will lose the initial "sectors", or, in the case of multiple partition only save one partition AND it will have "wrong" offset values in the PBR or bootsector.
• You need a tool to copy back the (modified) image file to the stick <- this CANNOT be done by IMDISK

This has nothng to do with the media type, it's simply that IMDISK has been designed as being filesystem (or partition, or volume) oriented as opposed to disk drive oriented.

• The "plainer" way is using a disk imaging software, since you need to modify the image often and you want to mount it to modify it without using a compression program, you should use a "forensic like image, it is very, very strange your report about Roadkil's DiskImage not working, it should work allright (as long as you DO NOT select for imaging a drive letter, but the actual PhysicalDrive), I already gave you a list of imaging programs, if you are allright with command line I recommend dsfo/dsfi.
• You can use IMDISK allright to modify the contents of the image, BUT you cannot SAVE a copy of it when mounted, as the copy will miss some parts, I suggested you a couple of drivers capable of mounting the whole PhysicalDrive, and a post where more known tools are listed.
• Once the image is mounted you can use the app in #1 above to take another image of the mounted PhysicalDrive.
• The same tools in point #1 will do.

Another approach, as long as you never modify the partition table of the stick, is to image, again with one of the apps #1 only the partition (or volume or filesystem or logical drive or "drive letter") and use IMDISK to modify it, BUT if you SAVE a copy of the IMDISK mounted image, you will need to correct the "wrong" data in the PBR before restoring the image to stick.

I hope now the matter is more clear.

Wonko

Ok, let me clarify a couple of things, I am able to backup and restore images to and from my flash device using Roadkill's DiskImage utility, however I am not able to mount those images in ImDisk as I would like to do. I don't quite understand what you mean by 'INTEGRAL' but as far as I can tell RoadKill's DiskImage utility makes a COMPLETE image of my drive (I was able to verify this by using his SectorEdit utility alongside of an image file created by using DiskImage opened in a traditional Hex Editor, while I did not compare the entire contents the first screenful of each program appeared to match exactly), When I backed up my data using Disk Image I did so by accessing the assigned drive letter, not by pointing it to a physical disk (in truth because I did not know which one my flash device was as I have a total of 4 that show up in the list when I use the dropdown menu), by pointing it to the drive letter it should as far as I can tell have backed up the partition that the drive letter was assigned to not necessarily the entire drive, now if I'm understanding you correctly ImDisk should be able to mount the image file of the partition without having to worry about any of the things like the MBR and hidden sectors and all that extra crap, but the plain fact is that it doesn't, I will try to figure out which physical drive my flash device is and try making an image from the physical drive and mounting it, with any luck that will work, I'll let you know if I have any luck. I have also found a few other utilities which are supposed to allow me to dump a raw image of the partition OR the entire drive (at my choosing supposedly) to an image file, I will try to use one of those utilities to make an image file and then try to mount it in ImDisk, with any luck it will work. Again I thank you for taking the time to work with me on this matter and I apologize for any misunderstanding due to my lack of understanding as I am more of a hardware person than a down and dirty software person, I grew up using PC's before Windows was even released, heck my first hard drive was a 40mb Maxtor XT1140 MFM/RLL hard drive, before SCSI and even IDE became standardized. Ask me COM port addresses and IRQ's and what not and I'm good, ask me to figure out how files are stored and I get lost (especially when dealing with NTFS, I did figure out on my own how to recover files in FAT12 filesystems using Debug before microsoft even included an undelete utility with DOS though).

Thanks again,
bartman2589

[Olof Lagerkvist]

I'm understanding you correctly ImDisk should be able to mount the image file of the partition without having to worry about any of the things like the MBR and hidden sectors and all that extra crap, but the plain fact is that it doesn't, I will try to figure out which physical drive my flash device is and try making an image from the physical drive and mounting it, with any luck that will work, I'll let you know if I have any luck.

Do you see a list of partitions to select from when you right-click and select to mount this image with ImDisk? If this list is displayed but it does not work anyway, it could be that your flash drive uses a sector size that is not 512 bytes. Quite a few flash disks work this way. The problem is that the sector size is essential for ImDisk to know to calculate the offset where the partition really starts, but there is no way to tell from the image file alone which sector size the original drive where using.

There is a tool I call devioctl on my website that you can use to see the sector size.
http://www.ltr-data.se/opencode.html

devioctl geometry E:

Change E: to your actual flash disk drive letter and notice the value reported as Bytes per sect. Later when you mount an image of this drive, use the following syntax:

Example:

imdisk -a -f C:\image.img -b auto -S 2048 -m #:

Change 2048 to actual sector size reported for the drive and notice capital S for the sector size switch.

I have also found a few other utilities which are supposed to allow me to dump a raw image of the partition OR the entire drive (at my choosing supposedly) to an image file, I will try to use one of those utilities to make an image file and then try to mount it in ImDisk, with any luck it will work.

This could be better because you will then have an image of the partition only, not the entire drive so there is no need for ImDisk to know the sector size in this case. When you want to write it back to the physical drive, make sure to write to the partition and not the entire drive.

[Wonko the Sane]

... I grew up using PC's before Windows was even released, heck my first hard drive was a 40mb Maxtor XT1140 MFM/RLL hard drive, before SCSI and even IDE became standardized. Ask me COM port addresses and IRQ's and what not and I'm good, ask me to figure out how files are stored and I get lost (especially when dealing with NTFS, I did figure out on my own how to recover files in FAT12 filesystems using Debug before microsoft even included an undelete utility with DOS though).

My first hard disk was a 5 Mb one.

Why, in my day....:
http://www.boot-land...?showtopic=1908

...kids today.....



Wonko

[TheK]

My first hard disk was a 5 Mb one.

You had a hard disk? Luxery! Back in my days all we had was a Datasette with a broken rewind button so we had to rewind the tapes with our fingers!

[Wonko the Sane]

.... so we had to rewind the tapes with our fingers!

You had WHAT FINGERS?

***LUXURY*** at the time we weren't evolved that much, all we had were FINS!

... but we didn't need any of those new fancy things you have today to swim faster:
http://www.superiorh...m/HandFins.html



Wonko

[bartman2589]

Do you see a list of partitions to select from when you right-click and select to mount this image with ImDisk? If this list is displayed but it does not work anyway, it could be that your flash drive uses a sector size that is not 512 bytes. Quite a few flash disks work this way. The problem is that the sector size is essential for ImDisk to know to calculate the offset where the partition really starts, but there is no way to tell from the image file alone which sector size the original drive where using.

There is a tool I call devioctl on my website that you can use to see the sector size.
http://www.ltr-data.se/opencode.html

devioctl geometry E:

Change E: to your actual flash disk drive letter and notice the value reported as Bytes per sect. Later when you mount an image of this drive, use the following syntax:

Example:

imdisk -a -f C:\image.img -b auto -S 2048 -m #:

Change 2048 to actual sector size reported for the drive and notice capital S for the sector size switch.



This could be better because you will then have an image of the partition only, not the entire drive so there is no need for ImDisk to know the sector size in this case. When you want to write it back to the physical drive, make sure to write to the partition and not the entire drive.

You state that there is no way for ImDisk to figure out the sector size from an image, yet windows has no trouble determining the sector size used on each partition, shouldn't it be possible for ImDisk to 'parse' the image file before mounting it and somehow discern the sector size? I mean the information has to be present in the partition in order for windows to be able to access partitions that use nonstandard sector sizes, doesn't it? That being the case shouldn't ImDisk be able to retrieve that information from the partition image file? Or is it stored in the MBR?

You state that it's possible that my flash media was using a non-standard sector size, and that that is why ImDisk couldn't mount partition images made from it, I accept that, but what about my USB hard drive? I made partition images of that as well but ImDisk was unable to mount those too, I know that drive would have used whatever sector size the Windows format command decides on as default since it was just a 2.5" laptop hard drive that I mounted into an aftermarket enclosure, in theory ImDisk should have had no problems mounting partition Images from this device since it would have used the standard sector size, but as I pointed out ImDisk was unable to mount images made from this device as well (note: I did not try making a 'complete' image file from the physical drive).

Regardless, I finally figured out how to do what I wanted to do in the first place, it turns out that regardless of the method I used to make an image of the partition on either my USB Hard Drive (which was a standard 2.5" laptop hard drive mounted in an aftermarket enclosure, it was not formatted with any specific sector size other than whatever default windows uses when formatting drives) or my Flash Drive ImDisk would NOT recognize those images as already being formatted and containing data (even when I used the right click context menu item from windows explorer, the very one that ImDisk itself installs to make the image). What I finally had to do was to make a COMPLETE image of the PHYSICAL drive not just a partition/drive letter image (which as I said no matter how I did it ImDisk failed to mount partition/drive letter images). Once I made an image of the ENTIRE drive (even though there was only one partition on it), then ImDisk would successfully mount the image and recognize that data was already present in the image, I could then move files to and from the 'virtual drive' at will and ImDisk would save the changes when I unmounted the image, now before I could restore the image to the drive it originally came from I had to make sure I formatted the drive so that the file tables were in effect blanked out, if I failed to do this then after I restored the image if there was a folder or a file that I had deleted from the original image, that file or folder would still show up in the file listing, however if I attempted to open it I would get notified that the file or folder was corrupt and could not be opened, this indicates to me that Roadkill's DiskImage utility is not actually writing the image back byte by byte but rather only writing the file data and then 'updating' the file tables rather than overwriting the existing file tables (a pretty serious flaw in my opinion).

So here are a few observations I have made in my attempts to use ImDisk with both a USB Hard Drive and USB Flash Media (thumbdrive):

1. ImDisk is incapable of correctly accessing partition/drive letter images that it itself has created by using the right click context menu item from windows explorer.

2. ImDisk is apparently only able to mount images of entire drives, not of individual partitions (apparently this is regardless of what software was used to produce the image file). It may be that I simply an not able to provide ImDisk with enough information about the image however (even then I think it's reasonable to expect the 'Auto' option to be able to figure out the basic information for the user, however it was not able to do so when using a partition image).

I think ImDisk has good potential however it needs to work on the issues I sited above in order to be easily usable by those individuals who like me do not know much about sectors or block sizes or tracks etc...

However for now I'm just happy that I figured out how to do what I originally intended, I just wish I could mount individual partition images using the 'Auto' feature and then be able to write those images back to the disk (in instances where the physical disk has multiple partitions this would be a great benefit, but alas as I stated ImDisk seems to be poorly suited to mounting partition images).

I thank those that attempted to help me with this, and wish all of you good luck in whatever endeavors you undertake.

Thank you,
bartman2589

[Olof Lagerkvist]

You state that there is no way for ImDisk to figure out the sector size from an image, yet windows has no trouble determining the sector size used on each partition, shouldn't it be possible for ImDisk to 'parse' the image file before mounting it and somehow discern the sector size? I mean the information has to be present in the partition in order for windows to be able to access partitions that use nonstandard sector sizes, doesn't it? That being the case shouldn't ImDisk be able to retrieve that information from the partition image file? Or is it stored in the MBR?

Maybe I was not clear, but the problem with missing sector sizes is only a problem for complete images including the MBR. For partition-only images this is not an issue because the sector size is stored in the partition and the filesystem drivers can simply use this information and everyone is happy.

But for complete disk images including MBR there is no information about sector size available and ImDisk needs this information to be able to find the actual partition from the information about partitions in the MBR. For physical disks this is a setting in the actual disk driver so Windows can get sector size from there. This information is then of course lost when you create an image of the disk because the image contains actual disk data only.

So, if your problem is the opposite, as it turns out to be, the root of the evil is not a non-standard sector size in your case. The only reason I mentioned it was because I have had reports from a few users before who where trying to mount complete images made from USB pen drives with non-standard sector sizes. It worked for them to mount a partition-only image but not an image of the complete disk because ImDisk found an incorrect offset for the partition in the image because it used MBR data multiplied with an incorrect sector size which gave wrong results.

You state that it's possible that my flash media was using a non-standard sector size, and that that is why ImDisk couldn't mount partition images made from it, I accept that, but what about my USB hard drive? I made partition images of that as well but ImDisk was unable to mount those too, I know that drive would have used whatever sector size the Windows format command decides on as default since it was just a 2.5" laptop hard drive that I mounted into an aftermarket enclosure, in theory ImDisk should have had no problems mounting partition Images from this device since it would have used the standard sector size, but as I pointed out ImDisk was unable to mount images made from this device as well (note: I did not try making a 'complete' image file from the physical drive).

Once again, the only time non-standard sector sizes could be a problem would be in complete disk images including an MBR. Here you say that you did not try that, you just created an image from the partition only, in which case the sector size should not be an issue. Why it is still not working for you, I have no idea. I have pretty much never seen that problem, even though I have imaged many kinds of partitions and physical drives.

Regardless, I finally figured out how to do what I wanted to do in the first place, it turns out that regardless of the method I used to make an image of the partition on either my USB Hard Drive (which was a standard 2.5" laptop hard drive mounted in an aftermarket enclosure, it was not formatted with any specific sector size other than whatever default windows uses when formatting drives) or my Flash Drive ImDisk would NOT recognize those images as already being formatted and containing data (even when I used the right click context menu item from windows explorer, the very one that ImDisk itself installs to make the image). What I finally had to do was to make a COMPLETE image of the PHYSICAL drive not just a partition/drive letter image (which as I said no matter how I did it ImDisk failed to mount partition/drive letter images). Once I made an image of the ENTIRE drive (even though there was only one partition on it), then ImDisk would successfully mount the image and recognize that data was already present in the image, I could then move files to and from the 'virtual drive' at will and ImDisk would save the changes when I unmounted the image, now before I could restore the image to the drive it originally came from I had to make sure I formatted the drive so that the file tables were in effect blanked out, if I failed to do this then after I restored the image if there was a folder or a file that I had deleted from the original image, that file or folder would still show up in the file listing, however if I attempted to open it I would get notified that the file or folder was corrupt and could not be opened, this indicates to me that Roadkill's DiskImage utility is not actually writing the image back byte by byte but rather only writing the file data and then 'updating' the file tables rather than overwriting the existing file tables (a pretty serious flaw in my opinion).

I have never used Roadkill imaging software, but I suspect you are right in your assumption about how it works. You can try my rawcopy tool instead if you like, it is on my website as well. Example:

rawcopy -m C:\imagefile.img \\.\PhysicalDriveN

The N in \\.\PhysicalDriveN need to be changed to the disk number of the disk you are overwriting. It is zero-based but Disk Management shows them one-based, so if Disk Management shows number 6 for your drive you should type \\.\PhysicalDrive5 here. Please note that the entire disk is overwritten so make sure to use the correct one. You also of course use this tool the opposite way to create an image from the drive (which also could be good to make sure that you are manipulating the correct disk).

rawcopy -m \\.\PhysicalDriveN C:\imagefile.img

So here are a few observations I have made in my attempts to use ImDisk with both a USB Hard Drive and USB Flash Media (thumbdrive):

1. ImDisk is incapable of correctly accessing partition/drive letter images that it itself has created by using the right click context menu item from windows explorer.

2. ImDisk is apparently only able to mount images of entire drives, not of individual partitions (apparently this is regardless of what software was used to produce the image file). It may be that I simply an not able to provide ImDisk with enough information about the image however (even then I think it's reasonable to expect the 'Auto' option to be able to figure out the basic information for the user, however it was not able to do so when using a partition image).

I think ImDisk has good potential however it needs to work on the issues I sited above in order to be easily usable by those individuals who like me do not know much about sectors or block sizes or tracks etc...

I must say there are a few strange things you have came across here. If they were easily reproducible on any other machine it could of course be worth to try to correct something if there is something to correct. But for now, I just notice what you have seen so that I can use that information if anyone else will experience the same or similar behaviour in the future.

However for now I'm just happy that I figured out how to do what I originally intended, I just wish I could mount individual partition images using the 'Auto' feature and then be able to write those images back to the disk (in instances where the physical disk has multiple partitions this would be a great benefit, but alas as I stated ImDisk seems to be poorly suited to mounting partition images).

I thank those that attempted to help me with this, and wish all of you good luck in whatever endeavors you undertake.

Thank you,
bartman2589

Okay, I am glad that you took time to investigate what happened and found a solution.

[Wonko the Sane]

@Olof
JFYI, Roadkil's Diskimage can have as source (under NT) both a drive letter (partition) or a \\.\PhysicalDriven.

It behaves exactly as dd, your rawcopy or dsfo/dsfi.

I tried procuring a "surely good image" just to make sure there wasn't any problem with the imaging tool or with anything else, but it seems like bartman2589 is not much in the "try listening and do the suggested tests" attitude.

@bartman2589
if you are still around, please do the tess suggested with the "reference" little image and report what happens, I am pretty sure there is still some kind of misunderstanding on the subject at hand.



Wonko

[bartman2589]

@Olof
JFYI, Roadkil's Diskimage can have as source (under NT) both a drive letter (partition) or a \\.\PhysicalDriven.

It behaves exactly as dd, your rawcopy or dsfo/dsfi.

I tried procuring a "surely good image" just to make sure there wasn't any problem with the imaging tool or with anything else, but it seems like bartman2589 is not much in the "try listening and do the suggested tests" attitude.

@bartman2589
if you are still around, please do the tess suggested with the "reference" little image and report what happens, I am pretty sure there is still some kind of misunderstanding on the subject at hand.



Wonko

I think you're missing a few points:

1. I wanted to do this with a GUI only (for simplicity's sake).

2. I wanted something that works the way one would reasonably expect it to (ie.. no monkeying around to TRY to make it work when it should just plain work as far as I'm concerned).

Additionally you seem to miss the FACT that irregardless of how I made a partition image from a source physical drive ImDisk was UNABLE to properly recognize it!!!!!! If on the other hand I created a partition image and THEN mounted it with ImDisk and THEN FORMATTED IT, I could add files to it to my hearts content and subsequently remount it at any time AFTER I had done so, however partition image files that already contained data (imaged from a partion on a physical drive which was perfectly accessible through windows) would not successfully mount even though there was no MBR included in the image since it was of a partition and not of the entire physical drive!! As I stated I tried making the partition image file using the right click context menu item provided by ImDisk and by using DiskImage (I could find no way to make an image of the physical drive from ImDisk though, which is why I used DiskImage to make the physical drive image). I don't see how trying to mount the 'test' image will help as the problem seems to be with ImDisk's inability to correctly mount partition images (I have made a half dozen different partition images using both ImDisk's right click context menu entry in explorer and by using DiskImage and pointing it to a drive letter instead of a physical drive, and in EVERY single instance ImDisk was unable to successfully mount one of those images and recognize that they already contained data). Yet ImDisk had no problem with mounting a complete image of the physical drive (one which DOES contain all of the MBR data and additional data that exists on a physical drive in addition to the partition), again I say that it appears to be a problem with ImDisk's ability to handle partition images. When I first started using ImDisk I was not aware that it could handle complete images. I have verified that the partition images I was trying to mount did in fact contain data by using a hex editor and noting that I was able to actually read some of the text (which I believe was from some of the various files which were present on the physical drive). As I stated the partition image files made from my USB hard drive (initially made by using the context menu entry I have mentioned several times) would have used the Windows default block size so if I understand correctly ImDisk SHOULD have been able to recognize that there was data already present in the image file and as such I shouldn't have had any problem with ImDisk mounting those images and allowing me to access the data already present in the image file. And just to let anyone who was wondering know, my USB hard drive was an old 2 gigabyte drive (yes very old and small I know, but the size should not have presented an obstacle to ImDisk), and it was formatted using NTFS, my Flash drive however was also a 2 gigabyte device and in this case was tested using both FAT12 and FAT32 (neither of which resulted in a partition image file that ImDisk was able to handle, only when I created an image of the entire physical drive was ImDisk able to handle the image file properly). But to satisfy you I will try to mount the test images, ok, though I wouldn't be too surprised if it doesn't work. I will post my results when I can. However even if it does work it still won't answer the question as to why ImDisk wouldn't mount the partition images I made from my USB hard drive.

[Wonko the Sane]

But to satisfy you I will try to mount the test images, ok, though I wouldn't be too surprised if it doesn't work. I will post my results when I can. However even if it does work it still won't answer the question as to why ImDisk wouldn't mount the partition images I made from my USB hard drive.

Well, NO.

I am pretty much satisfied ALREADY, but thanks for caring.

It is very possible (actually 100% sure) that the tests won't solve the problem, nor answer the question, but in this moment we (at least myself) have not a yet a properly worded question.

Once we have it, i.e. we have a repeatable (good or bad) behaviour of IMDISK, Olof already showed interest in trying to fix it if bad (and possible) and I will try, as soon as I have fully understand the issues to help where I can.

In other words, if you have the patience and time to do some tests with us, there are good probabilities that we can help in fixing your current issue, but, much more than this, we have an occasion to "better" IMDISK or at least clear some aspects that have not been completely cleared yet.

So, and with my satisfaction put apart, you will contribute to the Community knowledge and to IMDISK development.



Wonko

[bartman2589]

This could be better because you will then have an image of the partition only, not the entire drive so there is no need for ImDisk to know the sector size in this case. When you want to write it back to the physical drive, make sure to write to the partition and not the entire drive.

Evidently you missed the part where I had used the right click context menu entry provided by ImDisk itself to make a partition/drive letter image and still was unable to get ImDisk to recognize that the image contained information already (which I did in fact verify by viewing the image file in a hex editor and also by viewing the physical partition in a sector editor, both appeared to be exactly the same). I had also used Roadkill's DiskImage utility to make a partition/drive letter image which failed to mount as well.

Anyway I tried the test image supplied and oddly enough the test image behaved properly even when I made an image of the partition only by using the context menu option in explorer, it still doesn't answer why the images I made in the exact same manner from actual (not virtual mounted) partitions previously would not mount properly for me regardless of what I tried, that's what is really frustating me about this (it's also what prompted me to make my initial post to this forum asking for help), I have reinstalled ImDisk at least a half dozen times and I still got the same behavior when I tried to mount the image files I created from my original USB Hard Drive (partition images not whole physical drive images).

Oddly enough I just tried to make an image of the partition only from my flash media last night and THIS TIME ImDisk was successfully able to mount it, I did not do anything different than what I had done in the past to make the image (I used the right click context menu entry as I had done many times in the past) so I am unsure as to what had been keeping ImDisk from successfully mounting images created previously, the only thing that's really changed in my system configuration since my initial failed attempts is that I recently installed the VDK driver you referenced and subsequently realized that it was a command prompt utility so I never actually used it. Regardless it seems that ImDisk is for some reason working the way it's supposed to now (though I am at a total loss to explain it). Anyway, again I wish to thank you for taking the time to try to help me.

Thank you,
bartman2589

CASE CLOSED !!! YIPPEEE!!!

[Olof Lagerkvist]

CASE CLOSED !!! YIPPEEE!!!

Sounds good. Thank you for using this software and reporting problems you experience with it. As I have said before, I log every problem report and it is valuable information to have should anything similar be reported in the future.

[Wonko the Sane]

CASE CLOSED !!! YIPPEEE!!!

Good.

....the only thing that's really changed in my system configuration since my initial failed attempts is that I recently installed the VDK driver you referenced and subsequently realized that it was a command prompt utility so I never actually used it.

Rest assured that installing VDK has no effect whatsoever on IMDISK.

But guess why I suggested the optional use of a GUI for VDK (actually giving you a "choice" between two of them)?

To mount the RAW image you can use VDK
http://chitchat.at.i...vmware/vdk.html
optionally using a pseudo GUI:
http://home.graffiti...ts/VDM/vdm.html
http://vmxbuilder.com/vdk-gui/

About the cause of your initial issues I have no idea as well, if I were you I would attribute them to a "glitch in the matrix" and live happily.



Wonko

[bartman2589]

Good.


Rest assured that installing VDK has no effect whatsoever on IMDISK.

But guess why I suggested the optional use of a GUI for VDK (actually giving you a "choice" between two of them)?


About the cause of your initial issues I have no idea as well, if I were you I would attribute them to a "glitch in the matrix" and live happily.



Wonko

Yep, and now I just need to figure out why VDK won't allow me to dismount images (using the VDKWin GUI, the dismount button is greyed out). Since I do play around with Virtual PC and even VirtualBox it might be nice to get that working the way it should too. Anyway Thanks Again!

[bartman2589]

You had a hard disk? Luxery! Back in my days all we had was a Datasette with a broken rewind button so we had to rewind the tapes with our fingers!

Well the hard drive was on my fourth PC compatible computer (assuming you count a PCjr & Tandy 1000HX as being PC compatible), my third was an old Amstrad PC, and my fourth was an actual PC-XT with EGA graphics. My first computer however was a Timex Sinclair 1000 (Z80 Processor) that my dad got free with the purchase of 2 color TV's (one for me and one for my sister) with an audio cassette recorder hooked up to save files. After that I got an Atari 400, then finally the PCjr.