On 3/25/2019 7:06 PM, Ken Brown wrote: > The second patch in this series enables opening a FIFO with O_RDWR > access. The underlying Windows named pipe is created with duplex > access, and its handle is made the I/O handle of the first client. > > I tested the patch in two ways. > > First,
[...] > The second test was the following sequence of commands in a bash > shell: > > $ mkfifo foo > > $ exec 7<>foo > > $ echo blah > foo > > $ read bar <&7 > > $ echo $bar > blah I just realized that this doesn't test *writing* to the fd of a FIFO opened with O_RDWR. If I change the third command to "echo blah >&7", it does test this, and the write fails with ECOMM. It turns out that the call to NtWriteFile in fhandler_fifo::raw_write fails with STATUS_PIPE_LISTENING. Corinna, I'll try to debug this, but since I know you're about to be AFK for a month, I thought I'd check to see if you have any idea why this would happen. The Windows named pipe that we're writing to was created by a call to NtCreateNamedPipeFile with access = GENERIC_READ |GENERIC_WRITE | FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES | SYNCHRONIZE, and it was put in nonblocking mode by a call to NtSetInformationFile with fpi.CompletionMode = FILE_PIPE_COMPLETE_OPERATION. Thanks for any suggestions. Ken
