Messages in this thread | | | Date | Sat, 22 Nov 1997 14:40:45 -0500 (EST) | From | "Steven N. Hirsch" <> | Subject | Re: SMB oddness (patch attached) |
| |
On Sat, 22 Nov 1997, Bill Hawes wrote:
> 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
| |