Author: pschweitzer
Date: Mon Nov 10 09:45:43 2014
New Revision: 65352
URL: http://svn.reactos.org/svn/reactos?rev=65352&view=rev
Log:
[NTOSKRNL]
So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice hack.
But, so far, only reenable it for the 1st stage: the most intensive storage stack stage (unless you start playing with partitions & formating in 3rd stage).
CORE-8732 #resolve #comment Bug is now properly hidden with r65352
Modified:
trunk/reactos/ntoskrnl/io/iomgr/file.c
Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?r…
==============================================================================
--- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Mon Nov 10 09:45:43 2014
@@ -404,6 +404,27 @@
/* Check if we can simply use a dummy file */
UseDummyFile = ((OpenPacket->QueryOnly) || (OpenPacket->DeleteOnly));
+ /* FIXME: Small hack still exists, have to check why...
+ * This is triggered multiple times by usetup and then once per boot.
+ */
+ if (ExpInTextModeSetup &&
+ !(DirectOpen) &&
+ !(RemainingName->Length) &&
+ !(OpenPacket->RelatedFileObject) &&
+ ((wcsstr(CompleteName->Buffer, L"Harddisk")) ||
+ (wcsstr(CompleteName->Buffer, L"Floppy"))) &&
+ !(UseDummyFile))
+ {
+ DPRINT1("Using IopParseDevice() hack. Requested invalid attributes: %lx\n",
+ DesiredAccess & ~(SYNCHRONIZE |
+ FILE_READ_ATTRIBUTES |
+ READ_CONTROL |
+ ACCESS_SYSTEM_SECURITY |
+ WRITE_OWNER |
+ WRITE_DAC));
+ DirectOpen = TRUE;
+ }
+
/* Check if this is a direct open */
if (!(RemainingName->Length) &&
!(OpenPacket->RelatedFileObject) &&