When I connect a USB stick, I can access it in, at least, two ways:
1) Using the drive letter, e.g. U:. Also it could be accessed via a path, e.g. C:\USB1.
2) Using the volume GUID, e.g. \\?\Volume{54fb9d05-e6c0-11e0-9c37-005056c00008}\
When I create a virtual drive with ImDisk, I can access it using option #1. Is there any way to get access similar to option #2?
Not exactly. ImDisk does not interact with volume mount manager, so there are no volume GUID objects created for ImDisk drives.
In essence, I wonder if there is a way to get access to the virtual disk file system without either mounting it to a drive letter or to a folder. I suppose I can get access to it as a "device" via \Device\ImDisk0, but I would like Windows to process the file system for me, just like when you use a Volume GUID instead of a Mount Point for the USB stick.
Here you are mixing native paths with Win32 paths and you mistakenly came to the conclusion that there would be any difference to access a device via, say \Device\HarddiskVolume0, \\?\C: or \\?\Volume{54fb9d05-e6c0-11e0-9c37-005056c00008}\. There is actually no difference at all. There is no such concept that you would access the "device" in one of the cases and the "filesystem" in one of the others. The only difference is that you use paths like \Device\HarddiskVolume0 when you call native functions in ntdll.dll and you use
\\?\C: or \\?\Volume{54fb9d05-e6c0-11e0-9c37-005056c00008}\ when you call Win32 functions in kernel32.dll.
They all point to the same thing in the end. If you have, say Volume{54fb9d05-e6c0-11e0-9c37-005056c00008} mounted to D: and C:\USB you can use the
dosdev and
junc tools (on my website) to see this:
dosdev -q D:gives you:
D: => \Device\HarddiskVolume1and
dosdev -q Volume{54fb9d05-e6c0-11e0-9c37-005056c00008}gives you:
Volume{54fb9d05-e6c0-11e0-9c37-005056c00008} => \Device\HarddiskVolume1and
junc C:\USBgives you:
C:\USB -> \??\VolumeVolume{54fb9d05-e6c0-11e0-9c37-005056c00008}\This means that if you can use
\\?\D: or
\\?\Volume{54fb9d05-e6c0-11e0-9c37-005056c00008} if you want to open the volume with CreateFile() in kernel32.dll and you use
\Device\HarddiskVolume1 if you use NtOpenFile() in ntdll.dll. If you want to open a file on the volume, say
MyTextFile.txt, you can use
D:\MyTextFile.txt,
\\?\Volume{54fb9d05-e6c0-11e0-9c37-005056c00008}\MyTextFile.txt or
C:\USB\MyTextFile.txt when you use Win32 API and
\??\D:\MyTextFile.txt,
\??\Volume{54fb9d05-e6c0-11e0-9c37-005056c00008}\MyTextFile.txt,
\??\C:\USB\MyTextFile.txt or
\Device\HarddiskVolume1\MyTextFile.txt when you use native API.
You can create any symbolic link to native paths for use with Win32 functions. This is for example what Volume Mount Manager does automatically when it creates GUID objects and it is what the subst command does when you create a drive letter for a path.
You can for example type:
dosdev -r ImDiskDevice0 \Device\ImDisk0or from your code:
DefineDosDevice(DDD_RAW_TARGET_PATH, "ImDiskDevice0", "\Device\ImDisk0")This will create a symbolic link called
ImDiskDevice0 that you can use from Win32 applications to access \Device\ImDisk0. So, you can specify
\\?\ImDiskDevice0 in a call to CreateFile() and other Win32 functions and
\??\ImDiskDevice0 or
\Device\ImDisk0 in calls to native API. If you have a file called, say
MyTextFile.txt on that ImDisk drive you can access that by specifying
\\?\ImDiskDevice0\MyTextFile.txt in a call to CreateFile() and other Win32 functions. If you call native functions in ntdll.dll the only difference would be that you can access it without creating a symbolic link first so you can specify
\Device\ImDisk0\MyTextFile.txt in a call to NtOpenFile().
So you see,
\Device\ImDisk0 gives access to the filesystem as well, not only the "device".
).
):
:
, I only have 
:
