Slow response from Win 95

[Andrew Tridgell]

> I notice that smbfs has comments in the change log about slow Win 95
> clients and some code to handle this.

The code in clientgen.c handles this better I think. Look for the
msleep() calls. The smbfs code is based on very old code from
smbclient, at some stage I think it would be worthwhile to re-work it
using the newer clientgen.c code as a base. The smbmount code needs
the same treatment.
 
> I have received reports from some people using smbclient to back up Win 95
> boxen that files are skipped as Win 95 is sometimes too slow to respond.

huh? It can't _skip_ files. How could it? The socket is a stream, if
it doesn't get a response back quickly enough then all it can do is
drop the connection, it can't decide "oh, let's do the next file". How
would it tell the win95 server to "forget that last command, I've
given up on it".

If files are being skipped then it could only be happening at the
directory listing level. I thought that I'd fixed those problems, but
if you have a test case that demonstrates a surviving problem then
please help debug it. 

The problem that I fixed was that win95 would sometimes give an error
back if you tried to do two directory operations without enough of a
pause in between (so it is not a case of win95 being too slow to
respond, it is a case of the response being wrong!). The clientgen.c
code detects this and sleeps for 100 ms then tries again.

Since I put that change in (which may very well be similar to what is
done in smbfs, I don't know) I wasn't able to produce any errors when
hitting a win95 box very hard with recursive directory listings.

A good test, btw, is to enable "recurse" then do a "du". If you do a
dozen of them and they all give the same total byte size then you can
be pretty sure you have no timing related problems in the directory
listing code.