open_file_shared()

[Lyle Seaman]

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
interpreter.
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
routers?

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.