[jcifs] Problem reading multiple writes from named pipe

[Michael B Allen]

> capture, but I did put together two C++ programs that mimic the
> behavior/protocol of our real applications.  They each write twice and
read twice as I discussed before, and the "server side" pipe is created
with the same options (0x80000003 and 0x6).

Your server program creates a transact named pipe but the client is doing
regular file io. I don't think that combination is considered "legal". I
think you just got lucky. On the wire I'm seeing basic file io style
messaging a la SMB_COM_{WRITE,READ}_ANDX and like PipeTalk.

Having said that I did get this to work. The PipeTalk example does the
standard file io style messaging however it uses a separate thread to
issue a read *first* that blocks. The idea is you write and and the read
request returns with the answer. Apparently sending a read before you
issue the write will provoke a transact named pipe server to generate the
more data error. Thus the problem.

Now the solution; since it's using standard file io just use
SmbFileOutputStream to write *first* and and *then* use SmbFileInputStream
to read. See the attacked FileIOTalk.java example. The disadvantage of
this is that the lack of a separate reader thread means the program can
hang if the message is ill formed or truncated. It would be better to
convert either the client or server to use a pipe mode that is compatible
with the peer.

There's one problem though. The SmbFileOutputStream and SmbFileInputStream
classes do not anticipate reading and writing the same file at the same
time. So they use open flags of either O_RDONLY or O_WRONLY. If you create
the SmbFileInputStream first you get "access denied" trying to write and
if you create the SmbFileOutputStream first you get "Access denied" trying
to read the response. Catch-22. You will need to change lines 94 and 95 of
jcifs/smb/SmbFileOutputStream.java to use O_RDWR instead of O_WRONLY. Also
it is important to create the SmbFileOutputStream first so that those
flags are used. I'll make this change in a future release. If the client
is writing I don't think it will hurt to also open for reading.

Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FileIOTalk.java
Type: application/octet-stream
Size: 1444 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20030501/11ad63d3/FileIOTalk.obj