- 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.
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
Multiple "error C4189: '[...]': local variable is initialized but not referenced".
Thanks to Yuntian Zhang, who hinted at this in CORE-11836.
CORE-11280
This avoids race conditions under high IOs and thus corruption on
the FS, or assertions failures in the kernel.
Easily triggered by building ReactOS on ReactOS ;-).
Until now, our support for dirty volumes was totally broken
to a point where, on FAT32 volume, the dirty couldn't even
be written nor read from the disk.
This commit totally rewrites its handling, for both FAT16 and FAT32
so that it's now fully functionnal. Furthermore, it also gets
totally compatible with our vfatlib, and thus, autochk.
Now, on mount, FastFAT will check if the volume is dirty or not, and
autochk will be able to ask for a repair if dirty. vfatlib will
repair the volume and remove the dirty bit. So that, on next
reboot, the volume will be mounted clean.
As a reminder, the dirty bit is set immediately after mounting
the volume, so that, if you crash or have a powercut, autochk
will always attempt to repair your volume (with more or less,
that's FAT!).
If you want to experience without breaking your FAT volume,
just boot, open a cmd prompt and type: fsutil dirty set c:
and reboot!
CORE-13758
CORE-13760
CORE-13759
This is a hack, and totally not the default behavior.
But it will allow autochk locking the boot volume in
order to verify it on boot, in case it would have
been improperly dismounted.
CORE-13759
This avoids initializing cache directly on directory
open/create.
The advantage is we reduce the load on cache manager
and on memory manager by avoiding creating everytime
a stream file object, and initializing cache for it.
This will avoid initializing cache for started
applications 'current directory' which is just opened
for having a valid handle but no read/write is performed
in it, by default.
This is a step forward for autochk.
CORE-14629
Before performing a read operation, FastFAT driver will
attempt to compute whether it would run out of stack
during the operation. If so, instead of attempting the
operation in the current thread, it will post the read
request to the overflow thread.
This should help with the regressions brought in by
94ead99e0c.
CORE-14601
