> Steven N. Hirsch wrote:
> > > I'm assuming only that the Win 3.1 server is somehow different, as the
> > > smbfs code works fine when talking to Win NT.
> >
> > I agree. It's fine here as well.
>
> I went back and reviewed the logs you sent before, and have a new theory
> of what's going wrong.
>
> You mentioned observing that the size of the tmp file remains at 0 until
> it finishes writing. I think what's happening is that each time we
> refresh the inode, the server says the file size is still 0. Then right
> after closing, the call to smb_file_read first does a revalidate, but
> the revalidate doesn't acutally check on the server because the inode
> has been updated so recently. So the generic_file_read routine thinks
> there's nothing to be read because the inode i_size is still 0.
>
> When you put a time delay between closing and opening for reading, that
> forced the revalidation to check with the server, and then the read
> worked.. We may not actually need a delay, just a guaranteed refresh of
> the inode.
>
> I think a reasonable way to fix this is to force a revalidation after
> closing for old_style servers. Do you observe this problem with Win 95,
> or just Win 3.1?
Unfortunately (or, fortunately, depending upon one's degree of
Microsoft-phobia) I do not have a Win95 installation available here.
Someone else will have to report back on this.
Others on the list have commented that all SMB servers reflect a zero file
size until after close. This tends to support my guess that we're seeing
a race with the kernel inode ageing.
Steve