what about the problem where file info retrieved via smbmount gets cached?Is this all within the same scope, or would that be considered a differentproblem? I know there's a doc in the samba source that suggests turningoplocks off in the registry on the NT server to remedy this, but I've hadno luck with them. The problem is quite frustrating when you needreal-time updated info for a particular file.This also seems like it has been a big hurdle.

> Matthew Vanecek <mev0003@unt.edu> wrote:> >> > On a more constructive note, what in NT/samba combination would cause> > the connection to drop, if everything is working normally?> > Even SAMBA has a parameter called "dead time." This is the time that a> connection that is idle will be considered "dead," and the connection> quietly dropped by the server. That means that, if there is no activity> after a certain amount of time, a SAMBA server configured this way will> exhibit the same behavior that NT does, i.e. dropping the connection> after a period of inactivity.> > This seems to be an occurrence that all of the various OS's (Win9x, NT,> SAMBA) understand very well: If they find that their connection has> been dropped, the next time they try to use it, they will simply> re-establish the connection, and proceed. However, this requires the> password information to be re-exchanged, and this is the key to SMBFS's> failure.> > The MS OS's have their own particular ways of maintaining password> caches, and so re-establishing these connections is just a matter of> course. For SMBFS, this is not so simple, since we desire to have good> separation between kernel and user space tools, something Microsoft can> only wish that they had...> > >From what I've seen posted on this problem before, it really does seem> to be a breakdown in the kernel-user interface between the smbmount> utility and the kernel itself.> > When the kernel goes to access an SMB share, and finds that the> connection has died, it sends a signal to the smbmount process, which> should be waiting around for exactly such a signal. When it catches it,> the smbmount utility is supposed to re-establish the connection, and> then pass that new connection info back to the kernel so that the> operation can be retried.> > When people have reported this problem before, the answer returned by> the developers seems to be "Well, we don't see that here. We can't> reproduce the problem. Why don't you attach a debugger to your smbmount> process, and when the problem happens, try to examine some variables and> maybe give us a clue what might be going wrong?"> > And the answer from the community seems to be a collective "HUH??" and> so, nothing happens that might fix the problem.> > Anyway, that's the way I see it.> > -- > fox@dallas.net (Fuzzy Fox) || "Just about every computer on the market> sometimes known as David DeSimone || today runs Unix, except the Mac (and> http://www.dallas.net/~fox/ || nobody cares about it). -- Bill Joy '85> > -> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in> the body of a message to majordomo@vger.rutgers.edu> Please read the FAQ at http://www.tux.org/lkml/>

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/