Jump to content











Photo
- - - - -

From Virtual Disk Device to a Volume


  • Please log in to reply
66 replies to this topic

#1 Sophia

Sophia

    Member

  • Members
  • 85 posts
  •  
    Netherlands

Posted 20 October 2011 - 11:30 PM

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?

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.

If it is not possible directly (somehow I feel that is the case :) ), can it be done via an additional driver or something of the sort?

#2 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 21 October 2011 - 12:17 AM

I wonder in what situations a need may occur to do what you described instead of what's available? Can a drive letter or path be used in automation tasks instead of {guid}? The task looks more file system principles of operation related rather than ImDisk itself, but Olof is obviously best qualified to offer an opinion. At the same time I feel, ImDisk shouldn't be "everything for everyone". :) However, hidden partitions remain accessible for certain tasks and devices despite not being shown with a drive letter.

#3 Sophia

Sophia

    Member

  • Members
  • 85 posts
  •  
    Netherlands

Posted 21 October 2011 - 12:52 AM

I wonder in what situations a need may occur to do what you described instead of what's available?

If you run out of drive letters and all your drives are FAT32, so you cannot mount it as a folder either :D

#4 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 21 October 2011 - 01:56 AM

Hmmm... It doesn't sound like a frequent flyer. :)

I think what you ask for is:

CreateFile function (see volume related at the bottom)

in conjunction with

Naming a Volume

#5 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1,008 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 21 October 2011 - 06:57 AM

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\HarddiskVolume1
and
dosdev -q Volume{54fb9d05-e6c0-11e0-9c37-005056c00008}
gives you:
Volume{54fb9d05-e6c0-11e0-9c37-005056c00008} => \Device\HarddiskVolume1
and
junc C:\USB
gives 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\ImDisk0
or 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". :)

#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,839 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 October 2011 - 11:27 AM

Just for the record.
MOUNTVOL:
http://ss64.com/nt/mountvol.html

Obviously if you don't have even one tiny NTFS volume, you are pretty much stuck.

:cheers:
Wonko

#7 Sophia

Sophia

    Member

  • Members
  • 85 posts
  •  
    Netherlands

Posted 21 October 2011 - 12:04 PM

Thanks for the in depth explanation Olof. It all makes so much more sense now (and makes me feel embarrassed about the nonsense I wrote earlier ;) ).

You are absolutely right - I was, and very likely still am, confusing things, but that's because I couldn't find a decent explanation of what is what.

However, now I have a way to access the contents of the virtual drive without mounting it... hooray! :)

#8 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 21 October 2011 - 06:34 PM

It looks like MOUNTVOL utility is the good tool for that.

Hi Olof,

Since you mentioned Symbolic links, I wanted to ask a related question:

Lets say, a few instances of Opera browser (same .exe file) can be launched on one PC using different user profiles. To have certain files of these profiles synced at all times (say Bookmarks), a Bookmarks file in one profile is replaced by a NTFS Junction Point to same file in a different profile on the same partition. It results in both linked files having a Junction red sign over them. The problem is, as soon as Opera is launched and reads & saves the Bookmarks file, it replaces the junction with actual copy of Bookmarks file, and the links get broken, as shown in the file's Properties.

I realize, its possible to block Write access to the Junction to prevent this, but it might torpedo the purpose of this trick (to keep both files cynced) and is also contrary to the definition of NTFS File Junction as a re-parse point. How to fix? :) Soft symbolic links don't work at all for files reparsing, as they're more shortcuts then links.

#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,839 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 October 2011 - 06:45 PM

It looks like MOUNTVOL utility is the good tool for that.

Not exactly, as in:

Not exactly. ImDisk does not interact with volume mount manager, so there are no volume GUID objects created for ImDisk drives.


But you can use Mountvol to map *another* "conventional" volume to a mountpoint and thus free a letter to be used with the IMDISK drive.

:cheers:
Wonko

#10 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 22 October 2011 - 01:27 PM

Sophia's question was about accessing "virtual disk file system", so its hard to say if it was limited to ImDisk mounted volumes only. But MOUNTVOL can be useful for others too.

Still not clear, why a File Junction Point can be replaced by an app with a regular file, when it should merely redirect to a different file, which should be re-saved instead. If it doesn't work for a sample app like Opera, it also might not work in other cases given here (like "symbolic links" Olof's suggestion above, unclear HARD or SOFT, but further detailed in Mark Russinovich's Windows Internals book) and on MOUNTVOL webpage...

#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,839 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 October 2011 - 01:38 PM

Sophia's question was about accessing "virtual disk file system", so its hard to say if it was limited to ImDisk mounted volumes only. But MOUNTVOL can be useful for others too.

But Sophia posted in a Forum called:
reboot.pro
→ Groups
→ Project forge
ImDisk
and posted this question:

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?
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 DeviceImDisk0, 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.


So I find really hard to say how it was NOT IMDISK related. (you know, a lot of people tend to start a thread in the appropriate forum and keep it on topic).

:cheers:
Wonko

#12 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 22 October 2011 - 02:54 PM

People often tend to generalize and also re-specialize their questions in a conversation depending on where it goes. It happens in just about every thread, and the degree of deviation is in the hands of the beholder.

Like in this thread, Symbolic Links were mentioned by Olof, but not explained, what type of links (he might not know that after all :)). So, exploring possible complications was utmost relevant - it all depends who's looking at it. :victory:

For no particular reason, as you say (but may result from a faulty symbolic link :dubbio: ):

Inside the Blue Screen

#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,839 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 October 2011 - 03:43 PM

... (but may result from a faulty symbolic link :dubbio: ):

Inside the Blue Screen

This may also provoke that :whistling::
http://technet.micro...ernals/bb897558

Anyway BLUE Screens of death are so 2000ish :ph34r:, I only have GREEN ones.
http://blogs.technet...14/3374820.aspx
but you can now choose a better combination of colours ;):
http://blogs.technet...11/3379158.aspx

:cheers:
Wonko

#14 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 22 October 2011 - 04:01 PM

The sad thing is, the above BlueScreen utility doesn't save a screen of the actual BSOD, but instead generates a fake BSOD appearance of an unrelated cause. So, the faulty symbolic link issue would remain unresolved. :dubbio:

#15 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,839 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 October 2011 - 04:31 PM

So, the faulty symbolic link issue would remain unresolved. :dubbio:

You mean the hypotheytical faulty symbolic link issue, rigth? :unsure:
There used to be utilities to save the BSOD:
http://www.windowsne...totextfile.html

Now replaced by the nice minidump viewer by Nirsoft :worship::
http://www.nirsoft.n...creen_view.html

:cheers:
Wonko

#16 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 22 October 2011 - 04:47 PM

Xmmm... I was under impression, a symbolic link caused BSOD screen would be impossible to save. :cold:

#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,839 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 October 2011 - 04:55 PM

Xmmm... I was under impression, a symbolic link caused BSOD screen would be impossible to save. :cold:

Why don't you create one, and then see if a minidump is created?

:cheers:
Wonko

#18 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 22 October 2011 - 05:04 PM

In my above example Opera merely overrides a hard link (created with Link Shell Extension) with a file, while the linked file remains intact. Its possible, Write permission must be revoked from the file Junction to reverse such behavior. However, it would contradict its definition. Yet it didn't result in BSODs so far, it was indeed a hypothetical scenario. :)

However, a PC Resume from Standby periodically results in BSODs, when Opera is left open with M2 (Opera Mail Client) running. This is a separate issue, indeed well reflected by the BlueScreenView utility, I don't want to address in this thread.

#19 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 22 October 2011 - 06:42 PM

According to above cited Windows Internals 5th Ed:

A reparse tag owner, either a File System Filter driver or the I/O manager, can choose one of the following options when it recognizes reparse data (in a File Junction):

■ The reparse tag owner can manipulate the pathname specified in the file I/O operation that
crosses the reparse point and let the I/O operation reissue with the altered pathname. Junctions
(described shortly) take this approach to redirect a directory lookup, for example.
■ The reparse tag owner can remove the reparse point from the file, alter the file in some way,
and then reissue the file I/O operation.


It looks like the second happens in the above Opera Bookmarks file scenario for an unknown reason - possibly because a Hard Link to a File is a compatibility feature with previous NTFS versions. While current Soft Symbolic File Links are also replaced with actual files at saving them in the above example, and current Hard Symbolic Links (Junctions) are merely folder / directory links on the same volume (thus not recommended by the above book) . :dubbio:

Not sure what this supposed to mean, but seems to restrict Reparse Points (Junctions) feature to merely Windows default internal Junctions (or requesting any app like Opera to have its own filter driver for Reparse Points...when creating or, possibly, even accessing them):

If the I/O manager receives a reparse status code from NTFS and the file or directory for which NTFS returned the code isn’t associated with one of a handful of built-in Windows reparse points, no filter driver claimed the reparse point. The I/O manager then returns an error to the object manager that propagates as a “file cannot be accessed by the system” error to the application making the file or directory access.

I wonder if Olof ever played with Hard or Symbolic File Link functionality... But IMHO it should be part of ImDisk testing procedure anyway. What's interesting, plenty of sources repeat MS info on how to create symbolic links. But no particulars on how to use them, especially relevant to writing files (as opposed to jumping directories).

#20 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 22 October 2011 - 08:36 PM

It looks like I might have found the (loosely undocumented) reason for the above example of overriding a symbolic link with a file (See Windows 7 section):

In Windows 7 and Windows Vista, when the working directory path ends with a symbolic link, the current parent path reference, .., will refer to the parent directory of the symbolic link rather than that of its target.

Not sure so, what to do about it, if understood correctly. In my example, a parent dir (an App Profile dir on C:) is a soft symbolic folder link to its actual dir on K: (which is done to avoid polluting the system drive) that in-turn contains a hard link (OR a soft symbolic file link) to the target file on K: in a different Profile dir of the same App (as the App has several different Profiles to allow run its multiple copies). And that link is replaced by the actual file first time the App saves the file. :)

Hence, the approach of using symbolic links is not that straightforward as Olof presented. :book:

#21 Sophia

Sophia

    Member

  • Members
  • 85 posts
  •  
    Netherlands

Posted 23 October 2011 - 01:23 AM

sambul61, if I didn't know better, I would say that you are trying to surpass Wonko's post count... :D

On a slightly more technical note...
does anyone know a way to persuade Windows Explorer to show a "symbolic link" and allow me to browse it "like a normal disk"?

Of course, Windows Explorer can open drive letters like "X:". In addition, it can open Volumes using the Volume GUID. It doesn't work by typing in the Volume GUID directly, but you can open Start -> Run and there type in the Volume GUID. When you click ok it will open Windows Explorer window listing the contents of the volume.

I wonder if it is possible to persuade Windows Explorer to open a drive using dosdev -r MyDrive DeviceImDisk0. I tried using run with ?MyDrive, but the above trick seems to work only for Volumes GUIDs.

After all, Windows Explorer can browser all sorts of non-drive objects like search results and custom shell objects.

Any ideas are very welcome ;)

#22 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 23 October 2011 - 02:23 AM

Sophia,

It's next to impossible to surpass Wonko's post count, because...our James Bonko (also known as Wonko In-Sane) was given a License to Kill by the Emperor, and will (ab)use it without a doubt at the first sight of approaching demise. :devil:

In addition to the sound dose of healthy critic, you managed to comprehend the above discussion to the degree allowing to keep asking new questions. :dubbio: Meanwhile, you can find symbolic links in Win Explorer right under your nose, like Documents folder (just look in its Properties), Application Data, etc. Unless a symbolic folder link is security protected from being viewed by YOU, simply click on it to browse the target folder or disk. Use Link Shell Extension to get more practice in creating such links.

I also have a slight suspicion, you tend to mix Command Prompt functionality with the one of Windows Explorer. :lightbulb:

#23 Sophia

Sophia

    Member

  • Members
  • 85 posts
  •  
    Netherlands

Posted 23 October 2011 - 03:02 AM

I also have a slight suspicion, you tend to mix Command Prompt functionality with the one of Windows Explorer. :lightbulb:


Em, in what sense did I mix the two up? :)

http://virtuallyawar...e-files-within/

According to this (and trying it out), you can use both Command Prompt and Windows Explorer to view a Volume using a Volume GUID. However, I didn't ask about how to make it in Command Prompt, because I am more of a Windows person so I prefer Windows Explorer to Command Prompt, well most of the time ;)

#24 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1,568 posts
  •  
    American Samoa

Posted 23 October 2011 - 03:22 AM

I was under impression, we're talking NTFS symbolic links here. Other than that, you might be able to clarify your question from this DOSDEV intro.

#25 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 10,839 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 October 2011 - 08:55 AM

Other than that, you might be able to clarify your question from this DOSDEV intro.

Just for the record, and to avoid possible misunderstandings, that dosdev is NOT the dosdev Olof wrote and was talking about, which is this one:
http://www.ltr-data.se/opencode.html/
http://www.ltr-data....iles/dosdev.zip
  • dosdev.zip - 2.85 KB - compiled 2006-03-08 - Command line interface to the DefineDosDevice() and QueryDosDevice() API functions. Defines, redefines and prints information about the emulated DOS devices in Windows NT. Very useful if you want to use any object in Windows NT object namespace from ordinary Win32 applications. (In Windows 95/98/ME this utility is equivalent to the SUBST command.)


:cheers:
Wonko