I've been trying to mount an FSKit volume at the location where FileProvider saves files: ~/Library/CloudStorage . I've discovered that FileProvider attempts to call setAttributes in order to assign a value for an access control list (ACL). This call fails, because FSKit does not support this attribute, and causes FileProvider to stop working. FileProvider refuses to continue beyond creating it's domain folder when this occurs. Do you believe this constitutes a valid enhancement request for FSKit and/or FileProvider?
FileProvider & FSKit compatability
I've been trying to mount an FSKit volume at the location where FileProvider saves files: ~/Library/CloudStorage .
Why? What are you actually trying to do here? Setting the specific issue aside, I'm not sure what the consequences of taking over that folder might be, but I'm not surprised that it failed.
I've discovered that FileProvider attempts to call setAttributes in order to assign a value for an access control list (ACL).
This actually has me a bit confused. What were the actual circumstances involved here? ACLs aren't actually stored as xattr's (at least not by the system itself) and, if they were, then I'd expect FSKit to block requests from ever reaching your file system.
Do you believe this constitutes a valid enhancement request for FSKit and/or FileProvider?
It's certainly reasonable to ask for FSKit to support ACLs. However, that doesn't mean FileProvider should allow itself to operate on your mount.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
Written by DTS Engineer in 901315022
Why? What are you actually trying to do here? Setting the specific issue aside, I’m not sure what the consequences of taking over that folder might be, but I’m not surprised that it failed.
The intention is to use both frameworks in tandem to take advantage of what each offers: namely, the file synchronisation provided by FileProvider and the fine-grained hooking of file system operations provided by FSKit. It would also be useful to display a custom UI on a long press using the FileProvider UI framework, which, as far as I know, is the only way to do this.
Written by DTS Engineer in 901315022
This actually has me a bit confused. What were the actual circumstances involved here? ACLs aren’t actually stored as xattr’s (at least not by the system itself) and, if they were, then I’d expect FSKit to block requests from ever reaching your file system.
When I wrote the original post, I was referring to the now-deprecated setAttributes call , not to xattrs.
Given the limitation raised in my first message, the remaining option is to build a custom file synchronisation workflow with FSKit to support a network file system. I still believe it’s reasonable to expect these two technologies to be interoperable. My concern is that an enhancement request for Access Control List support in FSKit would only address the first of many blockers to getting the two frameworks to work together. I still intend to raise an enhancement, but first wanted to see whether you had any further input on the points above.
namely, the file synchronisation provided by FileProvider and the fine-grained hooking of file system operations provided by FSKit.
In terms of core functionality, I don't think FileProvider provides any capability that FSKit doesn't, ignoring implementation details like specific xattr's. I'd actually go so far as to say that IF FSKit had come first, it's likely that FileProvider would never have been implemented.
It would also be useful to display a custom UI on a long press using the FileProvider UI framework, which, as far as I know, is the only way to do this.
The other option is a FinderSync extension, which shouldn't have any issue running on an FSKit volume.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware