Make sense to make it simpler. Then I would just propose a minor fix - to remove "even" on the last line because IO from the same file descriptor is allowed. """ Another important side-effect is that the locks are not advisory anymore: any IO on a locked file will always fail with EACCES, when done from a separate file descriptor. """ -- Best regards, Pavel Shilovsky вт, 16 мар. 2021 г. в 12:42, Tom Talpey <tom@xxxxxxxxxx>: > > 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) > >> > >
