lws at spinnakernet.com
Wed Apr 11 13:34:53 GMT 2001
Jeremy Allison wrote:
> Lyle Seaman wrote:
> > jonathan bright wrote:
> > > 1- how oplocks are broken before share modes are checked.
> > > (yes, i read the comment)
> > Breaking the oplock may cause the share modes to change as a side
> > effect of a close by the client previously holding the oplock. If that's
> > not clear enough, ask again. hint batch oplocks. absent this behavior
> > you might never be able to get that second open through.
> That's a pretty strange design though. Once a client has closed a
> file it really should ensure an update on the server (IMHO).
> The idea of keeping oplocks across file open/closes just "in
> case" the file will be opened again is rather risky (IMHO).
> This is one of the things I don't like about Windows oplocks.
1. I think it was Jeremy that pointed out that "batch" oplocks were a sneaky
hack thrown in to enhance the performance of .bat ("batch") files, which
(AIUI) are closed and re-opened after each line is read by the command
2. If you mean "keeping dirty data across open/close ... is risky", I agree.
*Sane* clients should perform flush-on-close, even if they continue to hold
the batch oplock. Thus, there is no harm done. Otherwise, losing the server
connection would hose any chance you had of safely pushing your dirty data
back, unless you throw correctness to the wind and just write it back as soon
as your connection returns.
Nobody would be mad enough to do _that_, would they?
3. Tridge said "you don't wait for responses to L2 oplocks." In that case,
if you're breaking a few hundred or thousand of them (for some hypothetical
heavily-shared file analogous to /etc/motd) how do you avoid hosing your
This is only one of the things I don't like about oplocks. Half a good idea,
too bad nobody read the literature on (eg) Sprite beforehand.
More information about the samba-technical