> Steven N. Hirsch wrote:
>
> > Another quick data point. I recompiled iozone with a sleep(1) in between
> > close and re-open of the temporary file. We're definitely dealing with a
> > race on one end or the other, because this cured the problem with read()
> > failing.
> >
> > Let me know what you'd like a reading on next?
>
> Hmm, very interesting result. So Win 3.1 has to catch its breath before
> it's ready to open the file again ...
You are sure that it's a problem on the server side?
> That would account for the difference with 2.0.xx smbfs, as the old code
> doesn't close the file when the use count goes to 0 -- only when the
> inode is deleted.
>
> What would help now is if you could put some more printks into smbfs to
> find what call is failing (i.e. how far it gets before Win 3.1 gives
> up.) (Probably in file.c for file_open, file_read, etc.) Then I can
> kludge up a timeout from closing time and empirically find how long a
> rest it needs.
Will do. I noted by observation that the file always shows up as 0 bytes
in length until after it's closed. This differs from Unix semantics and,
I assume, from the behavior of NT Workstation 4.0.
Steve