subject:"\[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"

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

2014-11-10 Thread Aleksey Bragin


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, pschweit...@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=65352view=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=65352r1=65351r2=65352view=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, LHarddisk)) ||
+(wcsstr(CompleteName-Buffer, LFloppy))) 
+!(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
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

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

2014-11-10 Thread Pierre Schweitzer

Not at all. Because it breaks most of the features we could expect from
1st stage. Such as formatting with something else than FAT.
So, having it enabled in 1st stage is a total defeat.
Having it disabled elsewhere just unlocks software that rely on volume
open (such as NTFS tools).

On 10/11/2014 10:50, Aleksey Bragin wrote:
 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, pschweit...@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=65352view=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=65352r1=65351r2=65352view=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, LHarddisk)) ||
 +(wcsstr(CompleteName-Buffer, LFloppy))) 
 +!(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
 Ros-dev@reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev


-- 
Pierre Schweitzer pierre at reactos.org
System  Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

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

2014-11-10 Thread 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, pschweit...@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=65352view=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=65352r1=65351r2=65352view=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, LHarddisk)) ||
 +(wcsstr(CompleteName-Buffer, LFloppy))) 
 +!(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
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

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

2014-11-10 Thread 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, pschweit...@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=65352view=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=65352r1=65351r2=65352view=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, LHarddisk)) ||
 +(wcsstr(CompleteName-Buffer, LFloppy))) 
 +!(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
 Ros-dev@reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev
 


-- 
Pierre Schweitzer pierre at reactos.org
System  Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

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

2014-11-10 Thread Ged Murphy

Barney?

On 10/11/2014 18:57, Pierre Schweitzer pie...@reactos.org 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, pschweit...@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=65352view=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=65352r1=65351r2=65352view=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, LHarddisk)) ||
 +(wcsstr(CompleteName-Buffer, LFloppy))) 
 +!(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
 Ros-dev@reactos.org
 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
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev



___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

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

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

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

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

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

5 matches

Site Navigation

Mail list logo

Footer information