Mount to Reparse Point?

I use multiple physical drives, and multiple partitions on these drives... This makes allocation of space and management of files much easier. I only have 1 drive letter, C:. This keeps Windows and Windows Installers "Happy". "Program Files" may well be a different volume to "Windows" and "Documents and Settings" but they all appear in the directory structure of C:\ just as they would if they were on the same drive and partition as a default Windows install would have it.

I'm happy with this, being both a *nix and Windows user, and treat C:\ as *nix / root. I even keep a C:\dev with reparse points for each '\\.\Device\HardDisk0\' '\\.\Device\CdRom0' etc mounted as 'C:\dev\hda' 'C:\dev\cd0'.

I'm looking forward to the day when Windows no longer uses Drive Letters as it's default means of identifying devices.

The question then...

ImDisk -a -t vm -f myimage.img -m C:\dev\vd0

or

ImDisk -a -t vm -f myimage.img -m \\.\Device\VirtualDisk0

which could then be junctioned to visible space from the Object Namespace, do not work directly. Is there some trick to achieving this, or is it simply not possible with the present implementation?

Please note, I am not looking to mount as drive Z: and then Junction Z:\ to a folder... I don't want a "drive letter" at all.

An example of something similar to what I'm looking at doing would be Microsofts' ImageX from the WAIK.

imagex /mountrw c:\winpe_x86\winpe.wim 1 c:\winpe_x86\mount

is their example for building a custom Preinstallation Environment 2.0 image. You can add files to C:\winpe_x86\mount as you would any other directory, and the changes are made to the image, as the mount directory is actually an empty directory with the image mounted in it.

This works, but the speed increase of a vm backed image would be excellent for application tuning in some cases... Hence why I would like to do this with ImDisk rather than ImageX.

The question then...

ImDisk -a -t vm -f myimage.img -m C:\dev\vd0

This surprises me a bit as I often use this myself and have never had any problems with it... Can you give me some details about what actually happens, error messages etc?

or

ImDisk -a -t vm -f myimage.img -m \\.\Device\VirtualDisk0

which could then be junctioned to visible space from the Object Namespace, do not work directly. Is there some trick to achieving this, or is it simply not possible with the present implementation?

This second code example is wrong for a number of reasons. The syntax \\.\Device\... is not correct, neither as a native path (should be just \Device\... in that case) nor as a Win32 path as the \\.\ prefix just tells Win32 to pass \??\ and the following path to the kernel without any other interpretation of the rest of the path. \?? is the directory where the symbolic links like the drive letters and things like COM1 etc are. I assume you are thinking about specifying a special device path and ImDisk devices are created as \Device\ImDisk0, \Device\ImDisk1 etc. You can select a number manually using the -u switch:

imdisk -a -t vm -f myimage.img -m C:\dev\vd0 -u 3

This will use the name \Device\ImDisk3 for the new device. So, in this case, if you already have a junction that points to \Device\ImDisk3\ you do not need to specify any mount point for the device of course as the existing one will immediately work.

You can use my junc.exe tool (no, it is not junk ) to manipulate junction points manually: http://www.ltr-data.se/files/junc.zip

Example:

junc C:\dev\vd0 \Device\ImDisk0\

This surprises me a bit as I often use this myself and have never had any problems with it... Can you give me some details about what actually happens, error messages etc?

Yes, I've figured it now... It was saying it was getting and Invalid handle in DevIO... but it seems to be that I do need to be careful how I qualify the source and target... Fully qualified always works, deference from (PWD) current working directory doesn't always, either as source or destination. I was working with ".\Someplace_Else" which it wasn't happy with, but it seems happy with Someplace_Else unquoted... which means "Someplace Else" is out of the question. :s I haven't managed to figure out why as examples I have seen seem to do quite similar, and the error is inconsistent, so it's always possible there is some other lock going on (from Explorer or such) in the background that I'm unaware of which is having greater influence over the situation than my syntax to the command.

Batch scripting, I'm also running into errors where the script is trying to perform operations before the Namespace has caught up... and placing carefully positioned PAUSE statements seems to be helping there, but with no feedback as to when the OS has caught up with what I've asked it to do the script is still being... erratic?

MkSparse Cache.img 10M

ImDisk -a -f Cache.img -m z:

Format Z: /fs:FAT32 /V:CACHE /A:512 /Q /Y

XCopy Cookies Z:\ /S

Pause

ImDisk -d -m Z:

MD CookieCache

Pause

ImDisk -a -f Cache.img -m Cookies

Is there any documentation on Errorlevels set by ImDisk other than the source... which I won't read well That I could instigate a delayed retry of an operation?

I'm mounting to Z: there to create the image, simply because XCopy is so dumb that it doesn't seem to see the reparse point and Format tries to format my entire C: drive. (Copy works, but has no recursion... I guess GNU "cp -r" might be an ally) My intention is to ultimately code this as a pure executable for distribution, (Delphi or VB6 or so, I'm not a C guru like your good self ) and I wont have to deal with XCopy then, but I'm prototyping with a batch file, because that's a language everyone knows, and as ugly as it is, it will let me "try out" various techniques very quickly.

:: Edit ::
WaitForFile.exe from http://www.gdps.dk seems to be helping and GNU "cp -r" is (of course) working a dream. But info on errorlevels would still be useful for the final work.

Is there any documentation on Errorlevels set by ImDisk other than the source... which I won't read well

No, sorry, at least not until now

I looked at the source and there were practically only a few error levels reported. I have introduced some more now and used constants for them in the source. They are right now:

enum

  {

	IMDISK_CLI_ERROR_DEVICE_NOT_FOUND = 1,

	IMDISK_CLI_ERROR_DEVICE_INACCESSIBLE = 2,

	IMDISK_CLI_ERROR_CREATE_DEVICE = 3,

	IMDISK_CLI_ERROR_DRIVER_NOT_INSTALLED = 4,

	IMDISK_CLI_ERROR_DRIVER_WRONG_VERSION = 5,

	IMDISK_CLI_ERROR_DRIVER_INACCESSIBLE = 6,

	IMDISK_CLI_ERROR_SERVICE_INACCESSIBLE = 7,

	IMDISK_CLI_ERROR_FORMAT = 8,

	IMDISK_CLI_ERROR_BAD_MOUNT_POINT = 9,

	IMDISK_CLI_ERROR_BAD_SYNTAX = 10,

	IMDISK_CLI_ERROR_FATAL = -1

  };

The last error code -1 ("fatal") is now used only in a very few situations that should not really happen, such as memory allocation failures for small memory blocks etc.

The error code 3 ("create device") is also when reporting errors when creating a new virtual disk but also used when reporting errors when settings are changed for existent drives such as extending size or adding removable characteristics etc.