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) &&