> 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

Reply via email to