From 411da63870aae108abc11a7237bdd80addad8502 Mon Sep 17 00:00:00 2001
From: Pierre Schweitzer <pierre@reactos.org>
Date: Mon, 10 Nov 2014 09:45:43 +0000
Subject: [PATCH] [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

svn path=/trunk/; revision=65352
---
 reactos/ntoskrnl/io/iomgr/file.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/reactos/ntoskrnl/io/iomgr/file.c b/reactos/ntoskrnl/io/iomgr/file.c
index 6b454d9b858..febc5e517b9 100644
--- a/reactos/ntoskrnl/io/iomgr/file.c
+++ b/reactos/ntoskrnl/io/iomgr/file.c
@@ -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) &&
-- 
2.17.1