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.
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
