This involves many changes/fixes in the floppy driver:
- Stop creating ourselves our DOS device, it's up to the MountMgr or to the kernel;
- Report each new floppy drive to the MountMgr (this is a hack for now);
- As a consequence, stop storing the symlink name into the DRIVE_INFO structure;
- Store the device name instead;
- On IOCTL_MOUNTDEV_QUERY_DEVICE_NAME, don't return DOS device, but device name;
- On IOCTL_MOUNTDEV_QUERY_DEVICE_NAME, properly return if buffer is way too small;
- Hackplement IOCTL_MOUNTDEV_QUERY_UNIQUE_ID so that it returns device name.
This fixes shutting down ReactOS under certain circumstances, where
the references were incremented, but no worker thread started.
Also, took the opportunity to clarify the WorkerReferences comparisons
where relevant.
CORE-16446
Because our disk.sys doesn't do anything related to PnP
(compared to disk_new.sys), forcibly declare our partitions
to the MountMgr so that it can references them and assign
them a DOS drive letter on demand later on.
This is required so that MountMgr can handle devices that are still
using class2 instead of classpnp.
Given we have no unique ID to return, we'll return device path, which
is far from perfect but which is enough for now to have everything
working.
This fixes memory smashing while attempting to volume
reparse index (we were previously trying to copy the
name on itself, in the middle of itself...).
This code won't go farther on FAT, it requires NTFS.
Now, with this, ReactOS can properly boot with MountMgr
handling DOS devices without any crash or code disabled.
Cf: what was written in 7608ac9.
Modifications in class2, disk, and ntoskrnl are still to
be committed to enable all this.
- Properly quit the active loop when we're out of work items;
- Fix timeout duration (setting it to 1s);
- Fix handling the "Unloading" variable in case of a shutdown
so that waiting loop is properly stopped;
- Documented why we're waiting on VolumesSafeForWriteAccess.
This fixes shutting down ReactOS with work items queued.
This is needed here because no one ever sets that event (properly)
created by SMSS though. A. Ionescu was explaining in 2018 that it's
autochk responsibility, but it doesn't seem to be the case in W2K3.
To be investigated.
This fix with all the previous ones and more uncommitted stuff (yet ;-))
allows reaching the first steps towards a NT5 storage stack:
https://twitter.com/HeisSpiter/status/1186199631740506112
On preflight to compute output size, device name & unique ID were
counted only once per device.
Then, on copy, these two were copied on every MOUNTMGR_MOUNT_POINT
structure. This is counter efficient (data duplication) but also,
it was overruning the output buffer, since the preflight was not
expecting these extra copies.
This is purely a copypasta error fix, which was causing MountMgrNextDriveLetterWorker
to fail as no drive letters were enumerated previously.
With that set of patches, MountMgr now properly assigns drive letters to
new devices!
Being TRUE doesn't mean the device is GPT and has a drive letter. It just
means that it's not a GPT device with GPT_BASIC_DATA_ATTRIBUTE_NO_DRIVE_LETTER
attribute. In short, if TRUE, it means that the device can receive a drive
letter mount point.
This fixes MountMgrNextDriveLetterWorker bailing out for any attempt to
assign a drive letter to a device.
We must query the target device, and not the symbolic link
we attempt to create. The later will always fail as it doesn't
exist yet.
This fixes MountMgrCreatePointWorker not working.
This fixes returning too small structure on an IOCTL_MOUNTMGR_QUERY_POINTS call.
The multiple MOUNTMGR_MOUNT_POINT structures were ignored and thus the data of the
first one were erased by the multiple structures.
MountMgr now returns consistent output on this IOCTL call.
They were wrongly pointing to the original target once rewritten
instead of pointing to the proper target: the device.
This notably fixes opening the MountMgr device from user
mode (to perform IOCTL calls, for instance), and might
also fix various bugs dealing with global namespaces.
This might have some various effects in ReactOS~.
