Implement support for recognizing the Btrfs volumes.
Patch by Peter Hater.
CORE-10892 #comment The fs_rec part has been committed, thanks!
svn path=/trunk/; revision=70955
Also had the nasty partition number hack to IOCTL_DISK_GET_PARTITION_INFO_EX.
It is required for some file system to work in ReactOS (teasing :-))
svn path=/trunk/; revision=70781
- Remove one hack that seems not to be required anylonger.
- Add a comment to highlight the usage of the infamous partition 0 hack (who's the IopParseDevice() hack friend!)
svn path=/trunk/; revision=70771
Cowardly refuse to continue processing (enumerating/reading) when stumbling upon a compressed entry.
This avoids infinite loops when enumerating, incorrect files contents when reading.
CORE-10814 #resolve #comment 'Fixed' with r70750
svn path=/trunk/; revision=70750
When discovering floppy controlers, immediately probe controlers to check whether they have a disk and if so, what's its geometry.
This avoids waiting for the first read, which will obviously never happen because FSD will try other operations depending on not set geometry.
This implies a modification in RWDetermineMediaType() to avoid infinite wait, in case there's no disk at all in the controler.
Addendum to r70725
svn path=/trunk/; revision=70746
Add the ReactOS famous... hack? fix? whatever? already present in FastFAT, NTFS...:
When accessing a floppy disk, our floppy storage stack can return that the disk type is unknown (some would say it's legit - see comments in FastFAT) and will also return a disk sector size of 0.
Then, when trying to read the floppy disk with said size, everything goes wrong (null length read is never a good thing). So, as in any other FSD in ReactOS, for disk sector size to 512 bytes in this really specific case.
This fixes BSOD when having a floppy drive in ReactOS (whatever its filesystem).
CORE-10464 #resolve #comment Fixed with r70725
svn path=/trunk/; revision=70725
Replace old bugzilla report IDs to their JIRA counterparts.
[LIBUSB]
The third parameter of IoRegisterDeviceInterface is a pointer (optional). Use NULL instead of 0.
svn path=/trunk/; revision=70680
Change the Blue Screen Font hardcoded into bootvid.dll to the Open Source "Anonymous Pro" font, which makes a nice 8x13 font.
Blue Screens now look like this: http://fs5.directupload.net/images/160106/ehv6245t.png
[BOOTVID_FONT_GENERATOR]
In case you find an even better font, you now have a nice little tool to test that font and generate the corresponding FontData array for bootvid.
svn path=/trunk/; revision=70507
- Fix a bug in FltpDetachFromFileSystemDevice so it correctly bails when we've walked the attached device list.
- FltpDispatch can come in at high IRQL. Thanks to Thomas for noticing that err.
- Add newlines to the end of DPRINTS (it's been a while...)
- The filter now loads and runs in the reactos FS stack.
svn path=/trunk/; revision=70495
- Plug in the dispatch routines. These are just pass through methods for now to get the filter up and running.
- Implement the FastIo handlers. The majority of these call the FastIo routines of the attached device object.
- Make sure we detach from devices that are being deleted in FastIoDetachDevice.
- Move the FastIoDetachDevice routine to a deferred call as it's too expensive to tie up a FastIo request.
svn path=/trunk/; revision=70488
For MSVC builds (using KDCOM kd64 WinDbg protocol): Bail out for droppable packets after a given number of retries, if no debugger is attached (list of droppable packets can be found in http://articles.sysprogs.org/kdvmware/kdcom.shtml section "KDCOM protocol", subsection "Droppable packets").
CORE-10541 #resolve #comment Finally fixed in revision r70417!
CORE-7106
svn path=/trunk/; revision=70417
Correctly fix the definition of DRIVER_FS_NOTIFICATION (done the same way as the other DRIVER_xxx "callback" functions; by the way you'll notice they are all NTAPI aka. __stdcall. This is not explicitely mentioned in the W(D)DK, because MS supposes you compile all your kernel-mode code in stdcall convention, the WDK environment coming with preset default compiler switches enabling that. But if you try changing them, you'll run into big troubles. In our headers on the contrary we explicitely mention the calling conventions).
[FLTMGR]
Fix FltpFsNotification to adhere to the correct DRIVER_FS_NOTIFICATION definition.
Addendum to r70410.
svn path=/trunk/; revision=70413
- Add the beginning of the fltmgr. It's called rosfltmgr for now so I can test in Windows.
- It's currently just base code which registers for file systems appearing (or disappearing), and attaches itself to them and all other mounted devices in their chain.
- Although it builds (touch wood), don't add it to a running system. The IRPs aren't plugged in yet and it'll just bugcheck lower down the stack.
svn path=/trunk/; revision=70409
Do not use the "LoaderBlock->u.I386.CommonDataArea;" hack to use FreeLdr's DbgPrint function inside KDCOM, for the simple reason that while it works when KDCOM just initializes, the memory area where FreeLdr's DbgPrint function is, gets erased when ReactOS is running. As a result, all attempts to call the DbgPrint function when tracing something in KDCOM at the end of life of ReactOS, just fails lamentably (it hangs).
We therefore cannot rely on external code to provide us with DbgPrint. Instead, implement a very simple DbgPrint function inside KDCOM, as done by KDGDB.
The KD serial port serving for debugging KDCOM is chosen dynamically amongst the other free COM ports.
This needs to be also fixed in KDVM.
[KDGDB]
Instead of hardcoding the KD serial port number serving for debugging KDGDB, determine it dynamically amongst the other free COM ports.
svn path=/trunk/; revision=70405
- Don't take a reference on the device object in ScsiClassClaimDevice since it's not going to be released before device removal. Inspired by classpnp. Fixes ejecting mass storage devices.
CORE-8911 #resolve
svn path=/trunk/; revision=70310
