[Samba] oplocks, kernel oplocks, kernel share modes, .. - how it all works?

Michael Tokarev mjt at tls.msk.ru
Fri Jan 20 11:32:39 UTC 2023


Unfortunately it becomes impossible to create any interesting discussion on this
list, because Rowland replies to everything and distracts the theme into his
view of the world.

I don't have any interest or time in fighting with his opinions.  Unlike
Rowland, I don't base my opinions on beliefs, but on facts which I know.

I asked quite specific question: how certain operations WORK NOW in samba.
What I received is something entirely different. And untrue at it too.
I can ignore what Rowland replies (because most of his replies missing
the point, like in this case). But unfortunately there's no way I know
to trigger interest by others.

20.01.2023 13:25, Rowland Penny via samba wrote:
> On 20/01/2023 09:40, Michael Tokarev via samba wrote:
>> 20.01.2023 12:21, Rowland Penny via samba wrote:
>>> you shouldn't locally modify files on a Samba share. This is because Samba has no way of knowing that said files have been modified locally.
>>
>> This defeats the whole purpose of samba as INTEROPERABILITY suite for *nix,
>> to begin with.
>>
>> There are numerous mechanisms exists on linux to know the file has been modified,
>> so the statement about samba having no way of knowing that is wrong
> 
> If you don't want to believe me, go and read this:

There's no need to believe. stat(2) system call is as old as unix.
If anything, samba can check the given file ON ACCESS with plain
old stat(2), and send a lease/oplock break request if change is
detected.

Linux has inotify for quite some time, too.

> https://lists.samba.org/archive/samba/2022-December/243469.html

You're referring to a thread which started by me in December.

Unlike most other your answers, this reply was actually useful
somewhat (I found this very link too before asking, though).

And I acrtually missed this very part of the reply by Jeremy, -
what is missing in current linux file change notification
mechanisms, so you declare them not fully functional?

Back to the topic: samba lives in unix (linux, - doesn't matter
in the context). And having local unix users is very common. And
doing file edits locally is very common. Whole world is using
samba this way, - accessing files locally *and* via samba. This
is the long-established fact.

Instead of declaring whole world as wrong, how about thinking
what to do to make things less painful?

Or failing that, how about putting this in BOLD in the samba
website, on the first page:

   SAMBA CAN NOT SHARE FILES WHICH YOU MODIFY LOCALLY

because 99% users don't know this.

This way, there will be significantly less stupid questions
on this mailing list too.

Ditto for local unix users vs moving everything to the AD.

/mjt



More information about the samba mailing list