Re: smb fix no-go...

Steven N. Hirsch (
Sat, 15 Nov 1997 10:36:08 -0500 (EST)

On Fri, 14 Nov 1997, Bill Hawes wrote:

> 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.