Vivek Verma <mailto:vivek_ve...@apple.com>
April 3, 2018 at 11:46 AM

Advisory locking as defined by POSIX is bunch of sentences thrown together which make no sense when you actually try to use it in a real world application.

AFP's locking protocol (https://developer.apple.com/library/content/documentation/Networking/Conceptual/AFP/UsingForkCommands/UsingForkCommands.html#//apple_ref/doc/uid/TP40000854-CH225-SW1) borrows some API elements (on macOS) from the advisory locking interfaces , so some calls may on the surface appear to work the same but it does _not_ completely support POSIX style advisory locking and that's why the macOS AFP client does not claim to support it. It has its own locking implementation which interface-wise may overlap a bit with the interfaces for advisory locking.

I appreciate this position, and I'm aware that POSIX locking has some holes. I also appreciate that AFP mandatory locking and POSIX file locking are not interchangeable and therefor AFP can't claim to support them.

However, at the end of the day, I really just want to find out what works and get some rudimentary understanding as to why and what the pitfalls are / might be.

I have a real issue with file corruption from multiple clients writing to the same set of database files/package. All of my code has been re-written to use the POSIX API (i.e. open(2) et al). If the POSIX API bridges to the AFP file locking mechanism on afpfs volumes in any predictable way—and I can deal with some inconsistencies—that would be really good news for my application.

I've already got POSIX file locking and advisory locking, via fcntl(2), to work. Getting any kind of locking on AFP volumes is the last big hole I want to fill.

James
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list      (Filesystem-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to