why doesn't the kernel enforce oplocks? (was: Re: [Samba] Re: How Samba let us down)

[Ben Johnson]

Thanks for the explanation.

I never understood why *nix doesn't implement some kind of file locking
mechanism that actually enforces file locks.  I can see why the
traditional "advisory" locking semantics are useful, but wouldn't a
locking system that is actually enforced by the kernel potentially be
much more useful?  Does anyone know why this hasn't been done?  Why
wasn't this done when oplock support was added?  is it out of desire to
maintain a standard?  I'm thinking about trying to implement it.

- Ben


On Thu, Oct 24, 2002 at 05:48:49PM +0000, jra at dp.samba.org wrote:
...
> 
> "Share modes". These are modes of opening a file, that
> guarentee an invarient - such as DENY_WRITE - which means
> that if any other opens are requested with write access after
> this current open has succeeded then they should be denied
> with a "sharing violation" error message. Samba handles these
> internally inside smbd. UNIX clients accessing the same file
> ignore these invarients. Just proving that if you need simultaneous
> file access from a Windows and UNIX client you *must* have an
> application that is written to lock records correctly on both
> sides. Few applications are written like this, and even fewer
> are cross platform (UNIX and Windows) so in practice this isn't
> much of a problem.
> 
...