Thank you for working on this hack (partial) removal!
After all, having it only in the 1st stage is a win over having it
enabled all the time.
Regards,
Aleksey
On 10.11.2014 12:45, pschweitzer(a)svn.reactos.org wrote:
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) &&