Re: How to use mandatory file locking on afpfs volumes
Re: How to use mandatory file locking on afpfs volumes
- Subject: Re: How to use mandatory file locking on afpfs volumes
- From: Vivek Verma <email@hidden>
- Date: Tue, 03 Apr 2018 11:46:51 -0700
> On Apr 3, 2018, at 10:53 AM, James Bucanek <email@hidden> 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:email@hidden> 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:email@hidden> 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden