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@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?re... ============================================================================== --- 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) &&