> Hi Steve,
> I've gone over your report and have a theory that would explain the
> problems. The significant facts are that the smb_proc_open fails on a
> R/W try, and that the open is being done implicitly in the write
> operation.
>
> The current smbfs saves the fileid obtained when it creates a file, so
> the file should already be opened in R/W mode after the creat() call
> succeeds. But obviously smbfs thinks the file isn't open, since it tries
> to open it. If the server really does have the file open R/W, then of
> course the second open attempt would fail.
>
> My theory is that WfW is using fileid 0 for the first open after a
> reboot, and the smbfs code doesn't think this is a legal fileid value.
> I've changed the code to accept 0 as a fileid following a successful
> create, but to print a message if this occurs. Hopefully this will take
> care of that problem ...
>
> BTW, are you having any time-stamp problems with your smbfs shares?
> There seem to be some weird timestamp problems (not on NT) that I'm
> trying to track down.
The only problem I'm having is a long-standing one. I'd really like it if
the Unix mtime stamp became the visible file timestamp (is it create in
MS-DOS?) when copying to smb shares. Once upon a time it did work this
way, and I really don't like "losing" file modify stamps when moving
across filesystems.
Otherwise, newly-created files display the correct stamp.
Steve