> On Apr 3, 2018, at 10:53 AM, James Bucanek <subscri...@gloaming.com> wrote: > > Kevin, > > I tested this in a variety of configurations. The tests consisted of setting > up an AFP shared volume and then testing open(2) using O_SHLOCK and O_EXLOCK > options when opening a file on that volume from two different client > processes. > > AFP server = Airport Extreme, Client #1 on machine A, Client #2 on machine B > AFP server = Airport Extreme, Client #1 on machine A, Client #2 on machine A > AFP server = machine C with macOS AFP Sharing, Client #1 on machine A, Client > #2 on machine B > AFP server = machine C with macOS AFP Sharing, Client #1 on machine A, Client > #2 on machine A > AFP server = machine C with macOS AFP Sharing, Client #1 on machine A, Client > #2 on machine C (same computer running the AFP server) > > In all cases, the open(2) O_SHLOCK and O_EXLOCK worked exactly as they would > with a volume that reports it supports POSIX file locking > (VOL_CAP_INT_FLOCK=YES). That is, if one client obtains a shared lock no > other clients can obtain an exclusive lock, and if one client obtains an > exclusive lock no other clients can obtain any lock. Most importantly, the > open() call does NOT return an EOPNOTSUPP error, which is what the man page > says it will do if "the underlying filesystem does not support locking". > > This is consistent in every configuration, with one notable exception: if you > open a file on a remote APF volume with O_SHLOCK or O_EXLOCK from a client > machine and you then attempt to perform a regular open() (without either > O_SHLOCK or O_EXLOCK) from a second process, the open will fail with a > "resource unavailable" error, just as if you had requested a file lock. This > is consistent with AFP-style mandatory locking, but inconsistent with > POSIX-style advisory locking.
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 <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. > > James > >> Kevin Elliott <mailto:kelli...@mac.com> March 28, 2018 at 5:15 PM >> >> >> Were you testing this on two different machines simultaneously? The point of >> AFP locking is to protect the file contents from simultaneous access on >> different machines, not within the same machine. >> >> -Kevin >> >> >> James Bucanek <mailto:subscri...@gloaming.com> March 13, 2018 at 12:18 PM >> Follow up on my own post... >> >> My intention is to perform file locking on remote volumes, including AFPFS >> volumes. So far, I've found no documentation on how to implement "AFP-style" >> mandatory locking using fcntl(). >> >> Then I remember that, while deprecated, the now-ancient FS API is still >> around. Plan B was born: use FSOpenFork's deny-read & deny-write permissions >> to implement file locking, then turn around and use open(2) to access the >> data. >> >> That didn't work. As soon as I opened the file via FSOpenFork, open(2) would >> fail with "resource not available" error. >> >> Hmm, that sounds exactly like what happens when open(2) tries to open a file >> that has been opened by another process with O_SHLOCK or O_EXLOCK. >> >> So it would appear that, rather than being completely different file locking >> mechanisms, FSOpenFork() bridges to the advisory locking provided by >> open(2). And when I rewrite my test code to use open(2) O_SHLOCK and >> O_EXLOCK to access the same AFPFS volume from two different clients, it >> works perfectly! >> >> Now I'm wondering why the AFPFS volume (this on a Time Capsule, by the way) >> reports VOL_CAP_INT_FLOCK=NO and VOL_CAP_INT_ADVLOCK=NO. The functionality >> of open(2) on that volume would appear to directly contradict that >> capability test. >> >> Can anyone explain this? >> > > _______________________________________________ > 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/vivek_verma%40apple.com > > This email sent to vivek_ve...@apple.com
_______________________________________________ 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