[NTOSKRNL]
authorPierre Schweitzer <pierre@reactos.org>
Mon, 10 Nov 2014 09:45:43 +0000 (09:45 +0000)
committerPierre Schweitzer <pierre@reactos.org>
Mon, 10 Nov 2014 09:45:43 +0000 (09:45 +0000)
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

svn path=/trunk/; revision=65352

reactos/ntoskrnl/io/iomgr/file.c

index 6b454d9..febc5e5 100644 (file)
@@ -404,6 +404,27 @@ IopParseDevice(IN PVOID ParseObject,
     /* 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) &&