CORE-17200
Helps reducing debug log noise like:
```
(drivers\storage\port\scsiport\ioctl.c:542) unknown ioctl code: 0x4D0018
```
The other notifications are already implemented there.
These are handled by the volume manager, which is currently
stubbed into ReactOS' partition manager.
See commit ed27d733f7 for what the deprecated versions
of IOCTL_MOUNTDEV_LINK_[CREATED|DELETED] are all about.
CORE-18139
When a partition is created, PartMgr notifies the volume manager
(FTDisk on Windows <= 2003, VolMgr on Vista+) of its presence.
(Note that currently in ReactOS, our partmgr does the job of both
PartMgr *AND* VolMgr.)
The VolMgr then sends a `GUID_DEVINTERFACE_VOLUME` PnP notification,
which is handled by the mount manager (MountMgr) as part of a
`GUID_DEVICE_INTERFACE_ARRIVAL` notification:
```
MountMgr!MountMgrMountedDeviceNotification -> MountMgrMountedDeviceArrival
followed by
MountMgr!MountMgrTargetDeviceNotification
```
When a partition is deleted, via e.g. Disk Management or DiskPart,
it can be observed, on Windows, that the PartMgr gets notified by
the PnP manager, as part of QueryDeviceRelations. Before actually
removing the partition, it notifies the VolMgr. The latter invalidates
any volume mounted on that partition (`*PartitionRemoved*` functions
for basic volumes), then requests (`*DeleteMountPoints` function)
the MountMgr to delete all the mount points associated to the volume:
```
VolMgr!*DeleteMountPoints
-> MountMgr!MountMgrDeviceControl -> MountMgrDeletePoints
```
**** THIS is the new functionality that is implemented for ReactOS ****
**** in the present commit. ****
Following this, a subsequent PnP notification is sent, which calls
```
MountMgr!MountMgrTargetDeviceNotification
-> MountMgr!MountMgrMountedDeviceRemoval
```
(Note that this observation somewhat invalidates the modification
made in ReactOS commit 62a4f9d42b : our MountMgr placed in Windows
*WOULD* receive a `GUID_TARGET_DEVICE_REMOVE_COMPLETE` target-device
notification...)
Finally, a `GUID_DEVICE_INTERFACE_REMOVAL` PnP notification is sent
to the MountMgr:
```
MountMgr!MountMgrMountedDeviceNotification
-> MountMgr!MountMgrMountedDeviceRemoval
```
CORE-15575
In addition, fix a PartitionId assignment copy-paste error in PartitionCreateDevice().
The returned standard UniqueId has the following format:
- Basic volume on MBR disk: disk Mbr.Signature + partition StartingOffset (length: 0x0C)
- Basic volume on GPT disk: "DMIO:ID:" + Gpt.PartitionGuid (length: 0x18)
- Volume on Basic disk (NT <= 4): 8-byte FTDisk identifier (length: 0x08)
- Volume on Dynamic disk (NT 5+): "DMIO:ID:" + dmio VolumeGuid (length: 0x18)
- Super-floppy (single-partition with StartingOffset == 0),
or Removable media: DiskInterfaceName.
- As fallback, we use the VolumeInterfaceName.
References:
- https://winreg-kb.readthedocs.io/en/latest/sources/system-keys/Mounted-devices.html
- https://stackoverflow.com/a/72787681/21852502
- Manual testing on Windows.
- Implement IOCTL_VOLUME_QUERY_VOLUME_NUMBER:
See usage example in:
7241cebfa2/mayfield/branches/spr/src/umapps/ndassvc/service/drivematch.cpp (L627)
- Stubplement IOCTL_VOLUME_IS_PARTITION:
The only type of volume we support right now is disk partition
so we just return success. A more robust algorithm would be
to check whether the volume has only one single extent, that
covers the whole partition on which it lies upon. If this is
not the case, return STATUS_UNSUCCESSFUL instead.
This driver works as complement to disk.sys/classpnp.sys from Windows 10
Manages partition PDOs and exposes them as volumes to mountmgr.sys.
The driver is almost complete, just some minor IOCTLs missing (will be
added on demand)
