[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 at 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