Visitar URL original
File Provider Respects Exclusion List File by giancarlov93 · Pull Request #11164 · nextcloud/desktop · GitHub
Skip to content

File Provider Respects Exclusion List File - #11164

Draft
giancarlov93 wants to merge 1 commit into
nextcloud:masterfrom
giancarlov93:fix/fileprovider-root-sync-exclude
Draft

giancarlov93 wants to merge 1 commit into
nextcloud:masterfrom
giancarlov93:fix/fileprovider-root-sync-exclude

Conversation

@giancarlov93

Copy link
Copy Markdown

Resolves

Summary

With macOS File Provider the extension never read a .sync-exclude.lst; only the exclude list the main app sends over XPC (setIgnoreList, the global list) was applied. A file such as a.excl was uploaded although the root .sync-exclude.lst contained *.excl.

This change makes the extension read the .sync-exclude.lst in the root container of the domain and apply it to the whole domain together with the global list, like the classic sync engine does for the root of a synchronized folder.

  • RootContainerExcludeList (new actor): finds the file in the local database, downloads it once per etag (concurrent callers share one download), caches the patterns in memory, treats a 404 as an empty list and returns a retryable NSFileProviderError when the file exists but cannot be read. After the extension itself uploads the file the contents are cached without a download.
  • FileProviderExtension: createItem, modifyItem and deleteItem use the merged matcher.
  • IgnoredFilesMatcher: pattern translation now follows ExcludedFiles in csync_exclude.cpp. Before, directory-only patterns (build/) never matched, and escapes, [!...] and a leading ] were not handled. Matching also receives whether the item is a directory.

Not covered, on purpose (kept out to stay focused): .sync-exclude.lst files in subfolders are still not read, and nothing is filtered in the server-to-local direction (same as the global list today). Items already synchronized are not affected retroactively.

Tests

  • RootContainerExcludeListTests (new, XCTest because the package's Realm-backed suites rely on the process-wide default Realm configuration, which a parallel Swift Testing suite in the package overwrites), IgnoredFilesMatcherTests (extended), ItemCreateTests (extended).
  • swift test in shell_integration/MacOSX/NextcloudFileProviderKit: XCTest 417 executed, 1 skipped, 0 failures; Swift Testing 122 tests in 14 suites passed (run on the branch rebased on master 1845220).

Manual test

On macOS with a locally built, development-signed app containing this change, against a test account: root .sync-exclude.lst with *.excl and skipdir/; created files and directories (also a 3410-file, 159-folder tree copied in one go), renamed into and out of excluded names, changed/removed/restored the list while running, restarted the extension. Excluded items were never sent to the server, everything else was uploaded. I have not tested the list being changed by another client (the etag path is only covered by the unit tests).

Known leftovers

swiftformat --lint (0.64.4, installed locally) reports findings in files this PR touches, but none on lines added here; they exist on master already.

Checklist

AI (if applicable)

Disclosure: the implementation, the tests and the commit were produced with Claude Code (claude-opus-5-5) and reviewed by me.

The File Provider extension never read a .sync-exclude.lst, so only the
global exclude list was applied to a domain. Read the exclude list file in
the root container once per etag, keep the patterns in memory and apply them
to the whole domain together with the global list, like the classic sync
engine does for the root of a synchronized folder. Exclude list files in
other folders are not read yet.

The patterns were translated differently from ExcludedFiles, so directory
only patterns such as "build/" never matched and escapes, "[!...]" and
leading "]" were not handled. Translate them as csync_exclude.cpp does and
pass whether an item is a directory.

Assisted-by: ClaudeCode:claude-opus-5-5
Signed-off-by: Giancarlo <giancarlo@giancarloviali.it>
@i2h3 i2h3 added this to the 36.0.0 milestone Oct 30, 2026
@i2h3 i2h3 added os: 🍎 macOS Apple macOS, formerly also known as OS X feature: 📁 file provider macOS File Provider Extension, more general also known as virtual file system. labels Oct 30, 2026
@i2h3

i2h3 commented Oct 30, 2026 •

Copy link
Copy Markdown
Collaborator

Thank you for your contribution! Please rebase your work onto the latest HEAD of master because an important and inevitable major change has landed (#11004). This changes a lot of call sites related to data persistence within the file provider extension. 🫣

Because your contribution is a feature addition, we assume it will target the next major release for shipping. According to our versioning, a port back to the 35 releases is not intended. This is good because it simplifies the process. The replacement of Realm with GRDB coming with 36 will temporarily require more effort for back ports because call sites differ and conflicts can be expected. But your pull request is not affected. 😌

Please do not forget to change your pull request state from draft to ready for review once you get there! 😊

And I think we might have an issue for this missing feature implementation in the macOS file provider but I could not find it. 🤔 Maybe you can check as well? Then we can link it.

@i2h3 i2h3 changed the title fix(file-provider): apply the .sync-exclude.lst of the root container File Provider Respects Exclusion List File Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature: 📁 file provider macOS File Provider Extension, more general also known as virtual file system. os: 🍎 macOS Apple macOS, formerly also known as OS X

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants