Handling (Un)Visited Directories Correctly

[juliusvaart]

Summary

Three fixes under one invariant: a directory whose contents are known must say
so, and one whose contents are unknown must not pretend otherwise.

visitedDirectory is the flag that carries this. Two things depend on it —
whether a directory is in the working set the remote-change scan walks, and
whether an empty local child set means "this folder is empty" or "nobody has
looked yet". Each commit fixes one place where the flag, or the answer derived
from it, was wrong.

Problems

A folder created on the Mac never received server-side additions. Files
added to it through the web UI, a public upload link, or by another user never
appeared. The framework considers such a folder already enumerated — it knows
the empty listing it just made and will not ask again — so if nothing marks it
visited it never joins the materialised set, the working-set scan never
PROPFINDs it, and no later enumerateItems exists to repair that.
Resolves #9688.

Browsing into a never-enumerated folder showed an empty view and a spinner
that never resolved. Finder's status bar read "0 items" for a folder holding
three subfolders on the server. childItemCount derived the number from the
local database, which holds a directory's children only once something has read
that directory — so for an unread one it returned 0.
NSFileProviderItem.childItemCount is optional precisely so a provider can say
it does not know, and 0 is not "I do not know", it is "this folder is empty".
Finder printed that verbatim, and the framework, told the container had no
children, had no reason to schedule a fetch. The extension sat idle because we
had told the system there was nothing to ask for.

An ordinary browse persisted no visit at all. visitedDirectory is
local-only, so it takes no part in isInSameDatabaseStoreableRemoteState. The
non-paginated depth-1 ingestion decided whether to persist its read target
purely on that comparison, and a directory's etag does not change because
somebody opened it — so reading an unchanged directory dropped the visit. The
paginated path already compared the flag explicitly and was unaffected.

Changes

1. Mark locally created directories as visited — grant a folder created on
   this Mac the same refresh subscription a browsed folder gets.
2. Report an unread directory's child count as unknown — return nil
   rather than 0 when the local set is empty and the directory has not been
   read. delete had been reading nil as "empty or a file", which was safe
   only while nil meant a file; it now asks whether the item is a directory,
   so a directory whose contents are unknown refuses a non-recursive delete
   instead of assuming it has nothing to lose.
3. Record a directory visit when nothing remote changed — persist the visit
   separately rather than by adding the row to metadatasToUpdate. That set is
   also the change set handed to the framework, and announcing a directory as
   changed on every first browse would re-queue its update-item job for a flag
   the framework cannot see.

Testing

Full suite green at 356 XCTest + 59 Swift Testing. Each commit builds and tests
standalone. New tests: ChildItemCountTests (107 lines), VisitedDirectoryTests
(120 lines); each was run against a deliberately broken build first to confirm it
fails without the fix. Two existing EnumeratorTests expectations asserted the
old 0 and move to nil, with the reason recorded at the assertion.

Note for anyone testing this by hand: the framework caches every item's
NSFileProviderItem and only refreshes that cache when the extension's
CFBundleShortVersionString changes. Rebuilding at the same version leaves the
pre-fix childItemCount values in place and the fix appears to do nothing. Bump
the version between builds.

Checklist

• Sign-off message is added to all commits.
• The commit messages are following The Conventional Commits specification.
• The commit history is clean with no merge commits.
  • How to rebase your commits
  • How to squash commits with rebase
• Uploaded screenshots from before and after for UI changes.
• Test(s) added to branch, with before/after results included in PR description, for performance improvements where applicable.
• Documentation has been updated or is not required.
• Backports requested where applicable (critical bugfixes).
• Labels added where applicable (bug/enhancement).
• Milestone added for target version.

AI (if applicable)

• The content of this PR was partly or fully generated using AI
  • I have read the guidelines for AI-assisted contributions.
  • I have read Nextcloud's AI Contribution Policy.

[i2h3]

@juliusvaart Please ensure this pull request is based on master (unless it really is just meant to be integrated into the specific major release branch and not any future releases as well) and opened to be integrated into master.

[juliusvaart]

Now based on master

[claucambra]

Thanks for the contribution! The code changes themselves look fine to me, but I have issues with the commenting in this PR. In general too much commenting and too verbose (typical of Claude 🙂)

[i2h3]

Looks good to me.

[claucambra]

One last small comment

[Rello]

/backport to stable-34.0

[github-actions]

Artifact containing the AppImage: nextcloud-appimage-pr-10751.zip

Digest: sha256:f0dcd3e24c54e358c13c9176b1bcb222eafe3aa8520721da887541f2b09bf902

To test this change/fix you can download the above artifact file, unzip it, and run it.

Please make sure to quit your existing Nextcloud app and backup your data.

[github-actions]

Artifact containing the Flatpak bundle: com.nextcloud.desktopclient.nextcloud.flatpak.zip

Digest: sha256:034a601c1b14f5955ed5568262c490ad46e1b2ba192944403eca84755adc7644

To test this change/fix you can download the above artifact file, unzip it, and install the bundle with:
flatpak install --user com.nextcloud.desktopclient.nextcloud.flatpak

Please make sure to quit your existing Nextcloud app and backup your data.

[i2h3]

@juliusvaart Please rebase your branch, run swiftformat . in the NextcloudFileProviderKit package folder and ensure the actions succeed (do not worry about the SonarCloud, it sometimes is not working reliably). As off now, I see only code formatting preventing a merge. 🙂