• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: How to use mandatory file locking on afpfs volumes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to use mandatory file locking on afpfs volumes


  • Subject: Re: How to use mandatory file locking on afpfs volumes
  • From: James Bucanek <email@hidden>
  • Date: Tue, 13 Mar 2018 12:18:57 -0700

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?

Thanks!

James


James Bucanek <mailto:email@hidden>
February 26, 2018 at 1:11 PM
More annoying questions...

How does one use "AFP-style mandatory file locking" in macOS (10.9...current)?

I'm trying to implement file locking/coordination across various filesystems and servers.

The man page for getattrlist() includes the following filesystem capability test:

VOL_CAP_INT_MANLOCK  If this bit is set, the volume format implementation
                     supports AFP-style mandatory byte range locks
                     via ioctl(2).

AFPFS (a.k.a. AppleShare) volumes, particularly those on AirPort Extreme / Time Capsule devices, return 1 for this capability. These volumes do not support flock() or fcntl(F_SETLK) style advisory locking.

I looked at the man page for ioctl(2) and it contains no real information. It says the commands for ioctl(2) are documented in <sys/ioctl.h>.

So I had a look at <sys/ioctl.h> and found very little there; it's basically an umbrella header for several other headers. So I went through them one at a time: <sys/ttycom.h>, <sys/ioccom.h>, <sys/filio.h> (the one I would have assumed it would be in), and <sys/sockio.h>. I could found no mention of any kind of file or byte range locking commands defined.

So, is it possible to lock files/ranges on an AFPFS volume using ioctl(2), and if so where are these commands defined?


_______________________________________________
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

  • Follow-Ups:
    • Re: How to use mandatory file locking on afpfs volumes
      • From: Kevin Elliott <email@hidden>
  • Next by Date: APFS root filesystem. All files' inode id have offset of 0x200000000
  • Next by thread: Re: How to use mandatory file locking on afpfs volumes
  • Index(es):
    • Date
    • Thread