Preventing Folder Creation in macOS FileProvider based Drives

Question

Created Jul ’25

Replies 2

Boosts 0

Participants 2

Currently, I use NSFileProviderItemCapabilitiesAllowsAddingSubitems on a folder to control the creation of sub-items (either folders or files) within a parent folder. However, this capability doesn't allow me to meet a requirement where I need to permit file creation but restrict folder creation.

I am seeking input on different options to achieve this requirement.

Note: One reactive approach would be to intercept folder creation within the createItem() event handler and reject it with an ExcludedFromSync error (without uploading to cloud). This would prevent createItem() from being reattempted on that folder, but the folder would still remain on the mount. Is there any way to delete it?

Answered by DTS Engineer in 850726022

Replying to myself:

I've asked the engineering team for their suggestions, but I want to better understand your goals before I recommend anything specific.

The engineering team pointed out that you can return in the completionHandler of createItem(...). This is implied in the online class reference, but very directly stated in the header comments:

"If the imported item is refused by the extension, it should return nil for the createdItem without any error. In that case, the source item will be deleted from disk. In case the item represents a directory, the content will be deleted recursively."

I should have thought of this originally, but the key point here isn't that you're specifically blocking directories; it's that your file provider needs to be able to arbitrarily block ANY object creation.

The dynamics of how things like file sharing work across services is so variable that there isn't really any coherent way for a service to "export" to the FileProvider system exactly what will/will not be allowed in an and given configuration, particularly since that configuration ITSELF is dynamic. The solution is to let you block whatever "action" you want and trust/assume that (if necessary) you'll handle explaining WHY the action was blocked on your own.

As an aside here, I'd strongly recommend using the header files as the primary documentation references. They're very well structured and quite thorough.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’25

Currently, I use NSFileProviderItemCapabilitiesAllowsAddingSubitems on a folder to control the creation of sub-items (either folders or files) within a parent folder. However, this capability doesn't allow me to meet a requirement where I need to permit file creation but restrict folder creation.

So, my first question here is "why"?

The problem with blocking directory creation is that the widespread usage of packages means that there are lots of "objects" which the user thinks of as "files" but which are actually directories. That can end up making your provider look fairly "arbitrary" and inconsistent.

I've asked the engineering team for their suggestions, but I want to better understand your goals before I recommend anything specific.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

1

Answer 2

DTS Engineer OP

Apple

Jul ’25

Recommended

Replying to myself:

I've asked the engineering team for their suggestions, but I want to better understand your goals before I recommend anything specific.

The engineering team pointed out that you can return in the completionHandler of createItem(...). This is implied in the online class reference, but very directly stated in the header comments:

"If the imported item is refused by the extension, it should return nil for the createdItem without any error. In that case, the source item will be deleted from disk. In case the item represents a directory, the content will be deleted recursively."

I should have thought of this originally, but the key point here isn't that you're specifically blocking directories; it's that your file provider needs to be able to arbitrarily block ANY object creation.

The dynamics of how things like file sharing work across services is so variable that there isn't really any coherent way for a service to "export" to the FileProvider system exactly what will/will not be allowed in an and given configuration, particularly since that configuration ITSELF is dynamic. The solution is to let you block whatever "action" you want and trust/assume that (if necessary) you'll handle explaining WHY the action was blocked on your own.

As an aside here, I'd strongly recommend using the header files as the primary documentation references. They're very well structured and quite thorough.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0