Re: [ros-dev] NPFS problems

[Thomas Weidenmueller]

Ge van Geldorp wrote:
>   After changes r18883/r18912 umpnpmgr.exe (and
> eventlog.exe) don't start
>  anymore. The problem is that they try to connect to the service control
>  manager using a named pipe (advapi32/service/sctrl.c function
>  ScConnectControlPipe). Before opening the pipe, a call is made to
>  WaitNamedPipe() to see if the pipe exists. This call currently fails,
>  resulting in failure of ScConnectControlPipe(), resulting in failure of
>  umpnpmgr.exe, resulting in network drivers not being installed, resulting in
>  no network connectivity.
>  
>  WaitNamedPipe() NtOpenFile()s the pipe and then issues a FSCTL_PIPE_WAIT
>  ioctl. The problem is that this end of the pipe is now connected to the
>  server end (which is already listening) during the call to NtOpenFile() (in
>  function NpfsCreate(), setting the PipeStatus to FILE_PIPE_CONNECTED_STATE.
>  NpfsWaitPipe first checks the PipeStatus and bails out if it's not 0
>  (passive waiting state). So, in our case NpfsWaitPipe fails, 'cause the pipe
>  is already connected. The patch below just makes NpfsWaitPipe return success
>  in case it's already connected, which solves the umpnpmgr problem. However,
>  I don't think it's the correct solution, after the FSCTL_PIPE_WAIT ioctl
>  returns WaitNamedPipe() will close its end, so the server end sees an
>  unexpected close.
>  
>  I have no clue how to proceed, and to be honest I'm not interested in
>  solving it myself. I'd rather see the author of the original patch take his
>  responsibility and fix the regression he introduced.
>  
>  GvG.
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>   
Well, I can revert my kernel32 fixes, but then i guess that npfs doesn't
ever get fixed ;) If you want me to, i'll do it immediately of course.

- Thomas