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~.
- Added SAL annotation
- Simplified local variables
- Replace counterintuitive `do {} while ()` loops with nice `for` loops
- Get rid of goto and its label, it can be simply avoided
- Do not use hardcoded ordinals, add missing '-private'.
Except for MSXML3, OLE32 and RSAENH, see commit bff824b2 for more details.
- SHSVCS: The 6 first exports are nonamed with ordinals. Replace exported
commented stubs by actual exported stubs instead.
Co-Authored-By: Timo Kreuzer <timo.kreuzer@reactos.org>
Fixes GCC 8 warning:
sdk/include/crt/mingw32/intrin_x86.h:76:12: error: 'memmove' offset [21, 40] from the object at 'DirContext' is out of the bounds of referenced subobject 'Attrib' with type 'unsigned char' at offset 19 [-Werror=array-bounds]
return memmove(dest, source, num);
^~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes a regression from 99fa38809f, which
replaced the kcom.h/stdunk.h versions (which zero memory) with local
implementations (which don't).
Standard C++ does not guarantee that memory is zeroed but several classes
rely on this, in particular for their m_Ref and m_bInitialized members.
Ideally the constructors should be fixed to initialize all required members,
but that task is error-prone so for now we simply restore the previous
behavior.
- Import cmdcnst.h and vga.h headers from the 'vga_new' VGA Miniport Driver,
that contain definitions related to VGA registers as well as command-stream
functionality.
- Replace a bunch of hardcoded values by their corresponding defintions.
- Replace "Captain-Obvious" comments in VgaIsPresent() with actual
explanations from the corresponding function in 'vga_new'.
- Simplify the VgaInterpretCmdStream() function, based on the
corresponding one from 'vga_new'.
- Use concise comments in the 'AT_Initialization' command stream definition.
- Import the 'VGA_640x480' initialization command stream from 'vga_new'
and use it as the full VGA initialization stream whenever the HAL
does not handle the VGA display (HalResetDisplay() returning FALSE).
Otherwise we just use the 'AT_Initialization' command stream that
performs minimal initialization.
- Remove unused AT_Initialization and other declarations from ARM build.
- VgaIsPresent(): Re-select the memory mode register before playing
around with the sequencer flag. Otherwise the VGA may not be detected
correctly from time to time.
- VidInitialize(): Simplify the initialization loop, reset AddressSpace
to its "default" value of 1 when calling HalFindBusAddressTranslation()
on 'NullAddress'.
Now for each request SenseBuffer is correctly set
and 3 attempts are made to be sure the STALL state is cleared and
the error is in something else.
Remove the usage of UFI_INQUIRY_DATA structure in favor of "standard"
INQUIRYDATA structure from scsi.h
Based in Vadim Galyant's patches to usbstor
* [ADVAPI32] Simplify RtlCreateUnicodeStringFromAsciiz() return value check
RtlCreateUnicodeStringFromAsciiz() returns a BOOLEAN, not a BOOL.
No functional change.
Addendum to
CORE-14271
* [USER32] Simplify RtlCreateUnicodeStringFromAsciiz() return value check
RtlCreateUnicodeStringFromAsciiz() returns a BOOLEAN, not a UINT.
Also, add a FIXME.
No functional change.
Addendum to
CORE-14271
* [USER32] Simplify RegisterClipboardFormatA/W() a bit
No functional change.
* [UDFS] Simplify SeSinglePrivilegeCheck() return value check
No functional change.
Addendum to
CORE-14271
Fixes GCC 8 warning:
drivers/filesystems/reiserfs/src/memory.c:874:5: error: this 'if' clause does not guard... [-Werror=misleading-indentation]
if (Mcb->RfsdFcb)
^~
drivers/filesystems/reiserfs/src/memory.c:877:2: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
if (RfsdLoadInode(Vcb, &(Mcb->Key), &RfsdIno)) {
^~
These are required by latest mingw-w64 stl and we are mixing this with our crt headers.
Define _CRT_NO_POSIX_ERROR_CODES in all modules that define their own constants.
Some mice give a logical min/logical max which is the maximum move
that they can provide. Those were wrongly detected as absolute mice,
and mouse pointer was mostly stuck at the upper left corner of the
screen.
Interface between both is not anymore the HidParser_* functions, but
the HidP_* functions and the AllocFunction/FreeFunction/DebugFunctions/
ZeroFunction/CopyFunction.
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
The last parameter of USBPORT_ParseConfigurationDescriptor is a pointer
to a boolean indicating whether any alternate interface settings were
found for the specified interface.
Interpreting it as an alternate setting value, as we did before,
would always override the alternate setting to '1' (if any alternate
descriptors were present), therefore selecting the wrong interface
setting, and possibly causing a buffer overflow on the InterfaceList's
Pipes array.
Found by Special Pool.
There can be other descriptors between the config descriptor and the
first interface descriptor, so we specifically need to check for
the interface descriptor type and skip anything before that.
We also need to guard against bLength == 0, which would cause an
infinite loop, instead of doing a second bDescriptorType check.
We previously only gave the device a hard-coded amount of time to respond,
which could lead to interpreting the contents of uninitialized memory as
a response. This would lead to an unreasonably large number of audio function
groups being detected.
A KSEMAPHORE mirrors what Haiku uses here, though it may not be the optimal
synchronization primitive for this case under Windows.
This protects against crashing in case of faulty/malicious hardware,
but also works around a bug in HDA_SendVerbs that causes it to return
invalid data, thereby suggesting more groups than are actually present.
This will avoid 0-sized allocations, or -1-sized allocations.
So far, it's maxed by hard value stored in TCPIP.sys. I believe
this is not right and would deserve a true fix
This is needed in order to avoid an infinite recursive loop between
disk!UpdateRemovableGeometry() and ntos!IoReadPartitionTable().
This does not happen with NT5+ disk_new.sys because it doesn't call
IoReadPartitionTable() in that situation.
- Simplify failure path for DeviceName query failure
- Don't make stable query failure fail the whole function call
Based on a patch by Vadim Galiant
CORE-15550
- Add missing parameter to a DPRINT.
- Print pointers using %p instead of %x.
- Move all executable code behind a functions initial DPRINT.
- Do not use non-trivial initializers.
- Check for NULL instead of using !.
- Add missing parentheses.
the type of device it should return must not be FILE_DEVICE_CD_ROM, but must be the actual underlying one!
This fixes recognizing *removable* USB keys as disks and not CD-ROMs.
CORE-13184
* Add an NDK header to define INIT_FUNCTION/INIT_SECTION globally
* Use _declspec(allocate(x)) and _declspec(code_seg(x)) on MSVC versions that support it
* Use INIT_FUNCTION on functions only and INIT_SECTION on data only (required by MSVC)
* Place INIT_FUNCTION before the return type (required by MSVC)
* Make sure declarations and implementations share the same modifiers (required by MSVC)
* Add a global linker option to suppress warnings about defined but unused INIT section
* Merge INIT section into .text in freeldr
Do not enable it yet, as it doesn't work in ROS for the moment :-(.
Its place in tree is not optimal (it should be with disk/class/etc.),
but I prefer keeping it close to actual driver for now.
All the work has been done so that it compiles and links with ReactOS
SDK though.
- Cache the RootFcb so that its cleanup can be handled separately
during dismounting.
- Force volume dismount at cleanup if the VCB_DISMOUNT_PENDING flag
is set.
- Actually dismount a volume if its VCB has been flagged as not good,
or if we force dismounting.
NOTE: In their *CheckForDismount() function, our 3rd-party FS drivers
as well as MS' fastfat, perform a comparison check of the current VCB's
VPB ReferenceCount with some sort of "dangling"/"residual" open count.
It seems to be related to the fact that the volume root directory as
well as auxiliary data stream(s) are still opened, and only these are
allowed to be opened at that moment. After analysis it appears that for
the ReactOS' fastfat, this number is equal to "3".
- On dismounting, cleanup and destroy the RootFcb, VolumeFcb and the
FATFileObject. Then cleanup the SpareVPB or the IoVPB members, and
finish by removing the dismounted volume from the VolumeListEntry
and cleaning up the notify synchronization object and the resources.
- During dismounting, and on shutdown, flush the volume before
resetting its dirty bit.
- On shutdown, after volume flushing, try to unmount it without forcing.
- Release the VCB resources only when we actually dismount the volume
in VfatCheckForDismount().
- Initialize first the notify list and the synchronization object,
before sending the FSRTL_VOLUME_MOUNT notification.
- If we failed at mounting a volume but its VCB's FATFileObject was
already initialized, first call CcUninitializeCacheMap() on it
before dereferencing it.
- Send FSRTL_VOLUME_LOCK, FSRTL_VOLUME_LOCK_FAILED and
FSRTL_VOLUME_UNLOCK notifications during volume locking (and failure)
and volume unlocking.
- Flush the volume before locking it, and clean its dirty bit if needed.
NOTE: In addition to checking for VCB_CLEAR_DIRTY, we also check for the
presence of the VCB_IS_DIRTY flag before cleaning up the dirty bit: this
allows us to not re-clean the bit if it has been previously cleaned.
This is needed for instance in this scenario:
- The volume is locked (it gets flushed and the dirty bit is possibly cleared);
- The volume then gets formatted with a completely different FS, that
possibly clears up the first sector (e.g. BTRFS ignores 1st sector);
- The volume is then dismounted: if we didn't check whether VCB_IS_DIRTY
was set prior to resetting it, we could attempt clearing it again! But
now that the volume's filesystem has been completely changed, we would
then try to modify the dirty bit on an erroneous position on disk!
That's why it should not be touched in this case during dismounting.
- The volume is unlocked (same comment as above), and later can be
detected as being BTRFS.
We first check if a socket is listening before
checking whether it has connections. This allows
properly returning listening address.
Furthermore, if it's listening, properly return
status so that it displays nice in netstat.
Result: https://twitter.com/HeisSpiter/status/1064245622323200000 :-)
This leaked at least one IRP for every write, making it the largest leak when
running with BTRFS as the system volume.
Thanks to Victor Perevertkin.
Submitted upstream thanks to Pierre:
https://github.com/maharmstone/btrfs/pull/106
Up to now, it was working by chance. Indeed, due to the invalid
ASCII check performed before calling FsRtlIsAnsiCharacterLegalHpfs(), the
macro is improperly called and overruns the FsRtlLegalAnsiCharacterArray
buffer. Fortunately, up to now, right after that buffer in kernel binary
there are strings which are more or less consistent with the flags that
are expected by the macro, causing a decent behavior of
FsRtlIsAnsiCharacterLegalHpfs() even for extended ASCII characters
(whereas FsRtlIsAnsiCharacterLegalHpfs() is only designed for ASCII
characters). But this is a totally out of control and wrong behavior.
A single change in the way the kernel was built could have caused the
CDFS driver not to work as previously.
I have made the choice to allow any extended ASCII character as done
for the unicode characters. This is a good compromise to avoid drastic
regressions for users having extended ASCII characters in their CD
file names.
This imports proposed upstream commit 1b6b625641dffb49951e60398e1a9c672318ea71
See pull request https://github.com/Microsoft/Windows-driver-samples/pull/278
CORE-14067
When we're about to close a file (ie, forget everything about it
and release any associated structure), actually delay it.
This allows keep data fresh in memory for faster reuse in case
it would be required. The effective closing will only happen after some time.
For specific operations, this will produce a real speed up in ReactOS.
For instance, with that patch, Winamp starts within seconds, instead of dozen
of minutes.
In most cases, it will bring ReactOS to performances it had before fixing
the huge leak in FastFAT (commit 94ead99) without leaking the whole FS.
For now, due to regressions, this is only activated for files and not
for directories. Once it gets fixed, it will be enabled for both.
CORE-14826
CORE-14917
For whatever (unknown) reason yet, this stream file object
seems to be deleted when still in use while installing
ReactOS on BtrFS partition, leading to use after free.
So, quick and dirty hack: leak it to prevent deletion.
CORE-13769
