Re: [ros-dev] [ros-diffs] [pschweitzer] 65352: [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, onl...

[Alex Ionescu]

Let me make a simple arrogant comment:

Don't try to fix hacks that I spent years trying to fix (and failed). They
just can't be fixed :P

Best regards,
Alex Ionescu

On Mon, Nov 10, 2014 at 1:45 AM, [e-mail] 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) &&

[Pierre Schweitzer]

Let me make a simple arrogant comment:

Challenge accepted :P

Best regards,
Pierre Schweitzer

On 10/11/2014 19:02, Alex Ionescu wrote:
> Let me make a simple arrogant comment:
>
> Don't try to fix hacks that I spent years trying to fix (and failed). They
> just can't be fixed :P
>
> Best regards,
> Alex Ionescu
>
> On Mon, Nov 10, 2014 at 1:45 AM, [e-mail] 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) &&
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev
-- 
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.

[Ged Murphy]

Barney?

On 10/11/2014 18:57, "Pierre Schweitzer" [e-mail] wrote:
> Let me make a simple arrogant comment:
>
> Challenge accepted :P
>
> Best regards,
> Pierre Schweitzer
>
> On 10/11/2014 19:02, Alex Ionescu wrote:
> > Let me make a simple arrogant comment:
> >
> > Don't try to fix hacks that I spent years trying to fix (and failed).
> > They
> > just can't be fixed :P
> >
> > Best regards,
> > Alex Ionescu
> >
> > On Mon, Nov 10, 2014 at 1:45 AM, [e-mail] 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?rev=65352&r1=65351&r2=65352&view=diff
> > > ========================================================================
> > >
> > > --- 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) &&
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> -- 
> Pierre Schweitzer <pierre at reactos.org>
> System & Network Administrator
> Senior Kernel Developer
> ReactOS Deutschland e.V.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev