The major change with this rewrite is the support for the mount
manager. Fstub will now assume that most of the devices are PnP
and that they are already registered to the mount manager.
It will thus ask the mount manager to assign the drive letter.
Fstub will keep assigning drive letters non mission critical devices
such as CDs, floppies and other removable devices.
See MountMgr:QueryPoints API test that will now return mount points :-).
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
This adds an evil hack to persuade libstdc++, which tries to import __acrt_iob_func from a DLL.
This can only be solved cleanly by adding a GCC-compatible C++ standard library to our tree later.
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.
