-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reworking the mount and unmount code. #392
Comments
Testing against vhd mounted on
The output of
whereas for ZFS, we only get
Using the command Now we return So we correct it to return 1. Now I get The need for elevated permissions is wrong, need to figure out why that is. |
Congrats with the steps forward. To my eyes that's more than impressive! |
PS. Mounting / unmounting VHDs also requires the elevation on my OS. An SO thread Allow non-administrators to use diskpart to mount VHDs? says:
This also reminds me about Now I noticed that VHDX files can be mounted and dismounted just from File Explorer. Still no luck from unelevated I haven't investigated yet into exactly what does it do when I click the EDIT: Looks like I will need to trace the C:\Users\saukrs> reg query HKCR\Windows.VhdFile\Shell /s
HKEY_CLASSES_ROOT\Windows.VhdFile\Shell\mount
CommandStateSync REG_SZ
ExplorerCommandHandler REG_SZ {9ab3b1c9-3225-4bb4-93b6-bfb3c0d93743}
HasLUAShield REG_SZ true
MultiSelectModel REG_SZ Document
HKEY_CLASSES_ROOT\Windows.VhdFile\Shell\mount\command
(Default) REG_EXPAND_SZ %SystemRoot%\Explorer.exe
DelegateExecute REG_SZ {9ab3b1c9-3225-4bb4-93b6-bfb3c0d93743} |
A quick shot revealed me nothing, except maybe the suspicious registry paths like these: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume\{3001e1ae-97fa-4722-a80d-79ac3549257b}
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{3001e1ae-97fa-4722-a80d-79ac3549257b} ... with the UUID matching output of C:\Users\saukrs> mountvol
<...>
\\?\Volume{3001e1ae-97fa-4722-a80d-79ac3549257b}\
X:\
\\?\Volume{5feefb5c-468a-4da8-9fcc-0dfba19dcab8}\
*** NO MOUNT POINTS ***
\\?\Volume{0869fa25-bd66-7074-6498-7f4d08d64db0}\
E:\ ... where I suppose it has something to do with AttachVirtualDisk function (virtdisk.h). MSDN writes:
Now I noticed: as soon as I launch One of them uses the same image of Explorer: Command line: C:\Windows\explorer.exe /factory,{75dff2b7-6936-4c06-a8bb-676a7b00b24b} -Embedding
Current directory: C:\Windows\System32\
Autostart Location: n/a
Started: 19:18:20 10/07/2024 And another is some COM Surrogate: Command line: C:\Windows\system32\DllHost.exe /Processid:{51A1467F-96A2-4B1C-9632-4B4D950FE216}
Current directory: C:\Windows\System32\
Autostart Location: HKLM\System\CurrentControlSet\Services\COMSysApp
Started: 19:18:21 10/07/2024 COM Surrogate process exits soon after that. Clearly this indicates to me about some IPC/RPC going on behind the courtain via COM technology. And reversing that will require the skillset that I currently lack, I think. |
Awesome, I would like to ignore the Access Denied, and sounds like I can. |
So mounting NTFS F: and F:\dataset, will also not show in mountmgr QUERY_MOUNT_POINTS
so that was a couple of days of debugging lost trying to get that to work. Now using It is interesting to note that both E:\dataset, and E:\dataset2 are "Folders" in explorer. But with Clearly the initial mount of E:\dataset is done with wrong target name.
|
Ah no unrelated, shows as "Mounted Volume" after I corrected something. |
True, a lot is missing. Can you share both outputs here + the command that generated them, please? |
I used PowerShell |
Thanks. This seems to be equal to Meanwhile I constructed a bit different PowerShell composite for easier reading: C:\Users\saukrs> powershell "get-wmiobject Win32_Volume | ft @{Label = 'Mount'; Expression = {$_.Name -replace '^\\.+', ''}}, Capacity, FileSystem, Label, DeviceID"
Mount Capacity FileSystem Label DeviceID
----- -------- ---------- ----- --------
...
F:\ 4320129024 NTFS NTFS Volume \\?\Volume{c27eb7f0-3284-43ef-9f12-c3405d3bcd64}\
F:\dataset\ 1073741824 EXT4 An EXT4 Vol \\?\Volume{776c48ee-fe39-4fa4-8e7c-9d07a3a0d176}\
1073737728 NTFS Inner NTFS Volume \\?\Volume{fa93785d-d1f8-4ff7-b562-f2f2cbd7665a}\
...
B:\ 41527803904 Btrfs A Btrfs Vol \\?\Volume{0869fa25-bd66-7074-6498-7f4d08d64db0}\ Just noticed that Windows sees my EXT4 volume as mounted only if I mount it under NTFS folder: #389 (comment) If I mount EXT4 by default (as a drive letter), the location/mount info is lost: C:\Users\saukrs> powershell "get-wmiobject Win32_Volume | ft @{Label = 'Mount'; Expression = {$_.Name -replace '^\\.+', ''}}, Capacity, FileSystem, Label, DeviceID"
Mount Capacity FileSystem Label DeviceID
----- -------- ---------- ----- --------
...
F:\ 4320129024 NTFS NTFS Volume \\?\Volume{c27eb7f0-3284-43ef-9f12-c3405d3bcd64}\
1073741824 EXT4 An EXT4 Vol \\?\Volume{776c48ee-fe39-4fa4-8e7c-9d07a3a0d176}\
F:\dataset\ 1073737728 NTFS Inner NTFS Volume \\?\Volume{fa93785d-d1f8-4ff7-b562-f2f2cbd7665a}\
...
B:\ 41527803904 Btrfs A Btrfs Vol \\?\Volume{0869fa25-bd66-7074-6498-7f4d08d64db0}\ (It's replaced with So in that regard Ext4FSD project is broken – it registers only directory-based mountpoints. It would be nice to combine both partial mechanics into one :) EDIT: I stand corrected – EXT4 drive letter is omitted from the mount list only when assigned using the Ext2 Volume Manager tool. When I assign it the Windows way, via Disk Management console, the mounted EXT4 drive letter appears as expected: C:\Users\saukrs> powershell "get-wmiobject Win32_Volume | ft @{Label = 'Mount'; Expression = {$_.Name -replace '^\\.+', ''}}, Capacity, FileSystem, Label, DeviceID"
Mount Capacity FileSystem Label DeviceID
----- -------- ---------- ----- --------
...
F:\ 4320129024 NTFS NTFS Volume \\?\Volume{c27eb7f0-3284-43ef-9f12-c3405d3bcd64}\
E:\ 1073741824 EXT4 An EXT4 Vol \\?\Volume{776c48ee-fe39-4fa4-8e7c-9d07a3a0d176}\
F:\dataset\ 1073737728 NTFS Inner NTFS Volume \\?\Volume{fa93785d-d1f8-4ff7-b562-f2f2cbd7665a}\
...
B:\ 41527803904 Btrfs A Btrfs Vol \\?\Volume{0869fa25-bd66-7074-6498-7f4d08d64db0}\ This probably means that Ext2 Volume Manager (its' mounting operation sequence) is also incomplete. |
FWIW, found a tool which assigns a drive letter for my EXT4 volume correctly, it's ChangeLetter. With it, the letter is seen by WMI (via PowerShell). It's written in C# and seems to be only using According to Creating Mounted Folders, this is enough:
Then I found an Inside Mountvol.exe article and its' tool that does only directory mount for volumes. The code aims at older Windows versions (circa 2008). Maybe because of that it also describes two additional things:
Anyway, it mounts my EXT4 volume on an empty NTFS dir just fine.
OpenZFS already seems to be sending that IOCTL, but I guess it's done in kernel mode: I am guessing if the userland-vs-kernel mode difference is insignificant for registration. I probably should stop flooding the ticket and migrate to discussions. Anyways, putting my findings here for now. |
Last two items:
|
No need to survive reboots, at least not that the moment. I have noticed that VHD mounts do create DISK and PARTITION types, so perhaps it is time to add PARTITION to the testing. Everyone says you don't need it, but might as well try everything. I am concerned my E: doesn't have "driveletter" assigned, so potentially perhaps I have 2 broken things, and I should work on one at a time |
OK so chatgpt suggests:
|
@lundman , thank you very much for such a useful masterpiece!
|
That is the goal :) Actually, unmouting is working much better with the new work. It's just that the mounts are only half recognised. |
Hah ok, so today I found out BusQueryHardwareIDs does not return a string. Only once you point that out, does chatgpt happily point out you need to handle it. Thanks.
I have finally had some small progress, I can load the Driver without pnputil complaining, so we can start moving forwards. There have been many small little bugs to tweaks. |
I wonder if there are any book written that could help. |
OK going to jot down what I have learned while I still remember. Using WinObj.exe to inspect the objects created, in the
So naturally, we also create Problem 1. I noticed that in Turns out the After that, I can confirm the symlink: Problem 2. We should also get an entry This turns out to be automatically created by calling For the longest time we had: Now we get a It could very well be we need to do two .INF files, like Btrfs does. Presumably they do that for a reason. We can follow their example eventually. (Second INF appears to be for the Volumes, ie our ZVOLs) After creating the In here, you are given the This completes the DriverLoad work, and we are up and humming. You can run things like
The VOLUME in However, using Problem 3 Mounting a OpenZFS dataset. Gets a bit vague, murky and hand wavey now. Create a new Call
I guess VCB then too? If I call Next up, Now create a new Setup the VPB passed along with the request, to point Now we can talk to But even then, our volume does seem "mostly created". I am uncertain if the differences are just that we are a
Comparing the Objects in WinObj after a ZFS WinObj
So it looks like we have all required entries and symboliclinks, at least if we remember we do not attach partitions. The ArcName seems to be related to boot support for later. Here is where it looks a bit wrong:
Mostly empty? Just like CDrom. |
BSOD on import on 2.2.6rc4, was fine on 2.2.3-rc6 |
Any clues as to why? cbuf? stack? |
|
Why would |
Yes this is when I do |
I can certainly fix the |
Might be a trigger on my system, still need to be confirmed. |
Re-writing the mount/unmount code, both to try to get it more correct, and further understanding.
Now when we start a mount request, we go through the steps:
Next up, we wait to receive the
IRP_MN_MOUNT_VOLUME
when we get it:At this point we can start talking to mountmgr to arrange the Volume driveletter, or the reparsepoint.
I have rewritten the code so that PDO and VDO are more separated, ie, the diskDispatcher() and fsDispatcher() code. When a IRP_MJ is not handled, we now pass it "down" with:
IoCallDriver(DeviceObject->AttachedDevice, Irp);
So an IRP received by the VDO, if not recognised, will pass it down which for us is the PDO. If that does not recognise it, it will pass it further down. (pnpmanager it seems). This appears to be the model that Windows uses. Not everyone bothers, but I am in too deep, so let's explore it fully.
The text was updated successfully, but these errors were encountered: