File Provider: case-insensitive collision check prevents mounting case-sensitive remote filesystems correctly

Question

Created 1d

Replies 1

Boosts 0

Participants 2

When a File Provider extension (NSFileProviderReplicatedExtension) mounts a Linux server via SFTP, remote directories containing files that differ only in case (e.g., "README" and "readme") are not represented correctly. The framework silently renames one file locally via the before-bounce mechanism, even though the extension reports both items with distinct identifiers and correct filenames.

NSFileProviderActions.h states: "Collision checks should be case insensitive even if the filesystem or file provider might allow two coexisting filenames differing only by their case."

This check runs in the framework before writing to disk. Placing the domain on a case-sensitive APFS volume via NSFileProviderDomain(displayName:userInfo:volumeURL:) does not help — the volume passes eligibility but the collision check still applies.

This breaks any File Provider extension that mounts case-sensitive filesystems where case-variant filenames are common (especially git repositories).

Is there any way to opt out of the case-insensitive collision check per domain? A supportsCaseSensitiveNames property on NSFileProviderDomain would solve this.

Boost

Answer 1

DTS Engineer OP

Apple

2h

Is there any way to opt out of the case-insensitive collision check per domain?

No.

The problem here is that this:

A supportsCaseSensitiveNames property on NSFileProviderDomain would solve this.

...would only move the problem further up the stack without actually fixing it. FileProvider ultimately needs to store the files it's syncing "somewhere" and, on the vast majority of systems, that location is a case-insensitive file system. Theoretically, it could layer on some system to handle that (for example, using side metadata or some kind of name encoding system), but the major benefit of a "sync directory" over a secondary volume is that the file sync solution lets you move files in/out of the sync directory without a formal copy operation.

That means any support FileProvider introduced that objects moved out of the directory either:

Modify the names to remove the collision.

OR

Fail or only partially complete the move.

...both of which break the expected behavior of the local volume.

One thing to keep in mind is that this isn't a "macOS" issue- the default Windows configuration is ALSO case-insensitive, which means the vast majority of ALL computers are case-insensitive. This is also the reason why most file syncing services are case-insensitive.

This breaks any File Provider extension that mounts case-sensitive file systems where case-variant filenames are common (especially git repositories).

Yes and no. The underlying issue here is that supporting case sensitivity means creating some kind of translation layer between the sensitive and insensitive components. What FileProvider is doing is pushing that translation layer into your extension instead of trying to provide it themselves. Again, this is in line with how most file syncing services work, except that most file syncing services shift that translation layer to the "import" side by enforcing case insensitivity at import.

In any case, while you could try and create some kind of "name mapping" system to handle the issue, I'm not sure the better approach isn't to stop using FileProvider and build a true file system using FSKit instead. That does mean that moving objects in/out of your container will require copying, but aside from that, FSKit can create a user experience very similar to FileProvider.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0