fnum chaining and pipes

[Andrew Tridgell]

This is mostly directed at Luke.

While converting the code to get rid of fnum I noticed that the IPC
pipes code doesn't seem to handle fnum chaining. This is where a
client does a OpenX+ReadX chain (or some other combination like
ReadX+Close) and the fnum from the first operation is supposed to be
used for the second.

To handle this for real files we use a chain_fnum (now called
chain_fsp) variable which is stored into whenever a fnum is generated
or extracted from the packet then is used by GETFNUM() (now called
GETFSP()) and reset whenever a new packet is started.

Do clients generate chained Open+Read requests on pipes? (I'd be
surprised if they don't!). How is this currently handled?

while we are on this topic, here is something for Jeremy. In your
various packet queueing bits of code, do you handle the chain_fsp
correctly? I'm thinking of the case where in a OpenX+ReadX the OpenX
causes a oplock break and the ReadX gets queued for later, does the
readX get the correct chained fnum from the OpenX when it is finally
dequeued? Remember that during the oplock break the chain_fsp may have
been clobbered by the client calling a open/close etc.

I know that our chaining code is a bit of a mess, maybe the above
problems (if they are problems!) will prompt us to redo it :)

	 Cheers, Tridge