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.
CORE-15575
Detect whether the disk is a "super-floppy", which is the name given
to partitionless disk having no MBR, with the unique partition volume
starting at sector offset zero and spanning the whole disk.
The name comes from the fact that at the partitioning level, the disk
"looks like" a large-capacity floppy disk.
This is typically how external removable (USB, ...) drives are
partitioned by default by Windows.
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq?view=windows-11#superfloppy
The kernel-mode functions IoReadPartitionTable() / IoWritePartitionTable()
report the drive layout of a "super-floppy" disk as follows:
an MBR-style disk containing only one single partition starting at the
beginning of the disk (StartingOffset == 0) without hidden sectors, and
its type being FAT16 non-bootable.
The disk NTFT signature is set to 0x00000001.
----
Additional bug fixes to make the feature work reliably:
- Make PartMgrGetDriveLayout() also update the FDO DiskData's
PartitionStyle and Signature/GPT DiskId for consistency (code moved
from PartMgrRefreshDiskData()).
- In FdoIoctlDiskSetDriveLayout[Ex](), if the disk is "super-floppy",
but the user wants to create more than one partition, fail the call.
(In the Ex call, fail also if the partition style changes.)
warning C4267: 'function': conversion from 'size_t' to 'ULONG', possible loss of data'
The OutputBufferLength member that was temporarily stored in
outBufferLength is already a ULONG, and IssueSyncIoControlRequest()
takes the length as a ULONG. So there is no need to use 'size_t' here.
- 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)
