[Samba] file leases and replacing files

[Michael Tokarev]

27.12.2022 21:09, Jeremy Allison via samba wrote:
> On Tue, Dec 27, 2022 at 10:17:01AM +0000, Rowland Penny via samba wrote:
..
>>> The problem is that when one replaces or modifies a file on linux
>>> which is "leased" on windows, windows client start acting in a
>>> weird way
..
>> Leases are a Windows thing, perhaps reading this might help to understand them:
>>
>> https://learn.microsoft.com/en-gb/archive/blogs/openspecification/client-caching-features-oplock-vs-lease
>>
>> As far as I am aware, altering or deleting a file (that has a Windows lease on it) directly on Linux, isn't recommended, Linux has no concept of 
>> 'leases'.
>>
>> My feelings are, if a file is in a directory shared by Samba, then do not touch them directly on the server.
> 
> 100% correct Rowland, thanks ! For Samba to break
> client leases when local processes modify files
> requires kernel support, which isn't fully
> functional on Linux (or anywhere else on UNIXes
> to my knowledge).
> 
> Accessing via smbclient is OK, as this is just
> another SMB access and will allow Samba to
> properly revoke leases.

Thank you for the answers!

Well, this is what I suspected initially.

And now we have an interesting situation.

Historically, we setup a software distribution system to multiple
locations (it worked over dialup too when it was the way to connect).
Two tarballs of whole thing, compared, made the delta, which is
distributed to every place. In there, it is applied to the local
tarball to construct the new tarball. This is a background.

Now, this tarball (including executables and data files) is
extracted to an empty directory, and a symlink is atomically
updated to point to the new version. And the old directory
is deleted.  So this is even worse than modifying certain
files, - it is something which samba can never notice.

All this is done automatically without user interaction, using
linux-provided tools.

And sometimes, we use rsync to transfer a single file, -
when there's an urgent bug to fix which can't wait for
the regular schedule.

With the context of the above (leases, and earlier oplocks),
I don't quite see how this all can be done in a way to be
friendly to windows.

Adding smbclient to the mix is already hardly realistic.
Starting from the auth stage, in both cases - when it is
done automatically on receiving the whole new version,
and for urgent rsync usages.  Especially on slower links.
Should we keep a password to login to samba running
locally to extract the tarball? How should users updating
files manually - who are using ssh to login - use smb
client from an rsync session? Hmm.

And it is even worse actually: all these samba servers
does not do auth at all, they're publicly accessible to
the lan, and export everything in *readonly* way!

After auth prob is solved (thou I've no idea how, for now),
I can compare two extracted directory trees and make a
list of files which are changed or deleted, and write a
script for smbclient to perform file operations over it.
It's clumsy but it might work (for new files there's no
need to bother).  But there, I immediately face an atomical
issue, when some files are updated and some are not..

There are 2 more ways which might possible work.

One is to mount this samba share on the local machine
using cifs, and perform all modifications on the mount.
This needs write access and auth still.

And another is to use "autonomous files" on windows
side to cache the contents of this whole thing locally.
This has its own drawbacks for sure, and I don't yet
know if that will ever work any better. One immediate
issue is how to trigger the cache sync on all these
machines which we don't have access to.

Any suggestions for this whole, larger picture? :)

Thanks,

/mjt