On 3/16/2021 1:39 PM, Pavel Shilovsky wrote:
Sure. Thanks!
I would put more details from
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-lockfileex
:
"""
Another important side-effect is that the locks are not advisory anymore:
any IO on an exclusively locked file will always fail with EACCES
when done from a separate file descriptor; write calls on
a file locked for shared access will fail with EACCES when done
from any file descriptor including the one used to lock the file.
"""
Thoughts?
I think it'll be important to define what "exclusive" and "shared"
mean from a Linux/POSIX API perspective, and that will get into dragon
territory. I don't think it's a good idea to attempt that in this
manpage. It is best to leave Windows semantics, and interop with
Windows clients, out of it.
IOW, I personally prefer Aurélien's simple version for now.
Tom.
--
Best regards,
Pavel Shilovsky
вт, 16 мар. 2021 г. в 03:42, Aurélien Aptel <aaptel@xxxxxxxx>:
Pavel Shilovsky <piastryyy@xxxxxxxxx> writes:
It is not only about writing to a locked file. It is also about any IO
against a locked file if such a file is locked through another file
handle. Right?
Yes that was implied, the write was a simple example to illustrate. I'll
update to make it more generic:
Another important side-effect is that the locks are not advisory anymore:
any IO on a locked file will always fail with EACCES,
even when done from a separate file descriptor.
If you have comments please provide direct text suggestion to save time.
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)
