lkml.org 
[lkml]   [1997]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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



\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.050 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site