Hi Tom, Thanks for taking a look. Tom Talpey <tom@xxxxxxxxxx> writes: > On 3/2/2021 10:48 AM, Aurélien Aptel wrote: > I'd suggest removing this sentence. It doesn't really add anything to > the definition. OK. > This is discussing the scenario where a process on the server performs > an flock(), right? That's perhaps confusingly special. How about This is about clients. Let's say the same app is running on 2 different Linux system that have the same Windows Server share mounted. The scenario is those 2 app instances use the same file on the share and are trying to synchronize access using flock(). Pre-5.5, CIFS flock() is using the generic flock() implementation from the Linux VFS layer which only knows about syscall made by local apps and isn't aware that the file can be accessed under its feet from the network. In 5.5 and above, CIFS flock() is implemented using SMB locks, which have different semantics than what POSIX defines, i.e. you cannot ignore the locks and write, write() will fail with EPERM. So this version can be used for file sync with other clients but works slightly differently. It is a best-effort attempt. Does this clarification changes anything to your suggestions? > "In Linux kernels up to 5.4, flock() is not propagated over SMB. A file > with such locks will not appear locked for remote clients." > "protocol, which provides mandatory locking semantics." OK. As it turns out, there is actually a 'nobrl' mount option to get back pre-5.5 behavior. I'll mention it and use your suggestions in v2. Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
