ekohl@svn.reactos.com schrieb:
Don't start services until the control pipe issues are fixed.
Updated files: trunk/reactos/subsys/system/services/database.c
Ros-svn mailing list Ros-svn@reactos.com http://reactos.com:8080/mailman/listinfo/ros-svn
Hi,
it is more wrong with the pipes. Compiling ros on ros doesn't work.
- Hartmut
Hartmut Birr schrieb:
Hi,
it is more wrong with the pipes. Compiling ros on ros doesn't work.
- Hartmut
Does this patch fix the bug?
Index: fsctrl.c =================================================================== --- fsctrl.c (revision 12698) +++ fsctrl.c (working copy) @@ -59,8 +59,6 @@ break; }
- -#if 0 if (ClientFcb->PipeState == FILE_PIPE_LISTENING_STATE) { /* found a listening client fcb */ @@ -84,7 +82,6 @@
return STATUS_PIPE_CONNECTED; } -#endif
current_entry = current_entry->Flink; }
Eric Kohl schrieb:
Hartmut Birr schrieb:
Hi,
it is more wrong with the pipes. Compiling ros on ros doesn't work.
- Hartmut
Does this patch fix the bug?
It doesn't fix the problem. I get:
F:\Sandbox\Reactos\tools>gcc -o rdel.exe rdel.c -pipe Assembler messages: rdel.c:101 fatal error: error writing to-: Permission denied (EACCES)Can't open {standart input} for reading : Invalid argument (EINVAL) compilation terminated.
It works without the '-pipe' parameter.
- Hartmut
Hartmut Birr wrote:
ekohl@svn.reactos.com schrieb:
Don't start services until the control pipe issues are fixed.
Updated files: trunk/reactos/subsys/system/services/database.c
Ros-svn mailing list Ros-svn@reactos.com http://reactos.com:8080/mailman/listinfo/ros-svn
Hi,
it is more wrong with the pipes. Compiling ros on ros doesn't work.
I suspect the pipechanges broke w2k cmd.exe also...
- Hartmut
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Gunnar Dalsnes schrieb:
Hi,
it is more wrong with the pipes. Compiling ros on ros doesn't work.
I suspect the pipechanges broke w2k cmd.exe also...
As far as I can see make.exe and cmd.exe are using CreatePipe() to create anonymous pipes. There was a bug in the NpfsClose routine that froze the caller of CreatePipe() if the write handle was closed before the read handle. This has been fixed.
Now a pipe is removed when the client fcb list and the server fcb list are empty. The old implementation removed a pipe when a pipes last server instance was closed no matter how many client instances were still open.
Regards, Eric