fix(dav): fail propfind for unavailable mounts

[gitedmond]

• Resolves: [Bug]: PROPFIND request returns 207 with empty directory on storage exception #63117

Summary

When an external mount becomes unavailable, View::getDirectoryContent() currently omits that mount and continues. For WebDAV PROPFIND requests, this can produce a successful 207 Multi-Status response containing an incomplete directory listing. Synchronization clients may interpret the missing mount or its files as server-side deletions.

This adds an opt-in strict directory-listing mode while preserving the existing lenient behavior for other callers. A Files-specific PROPFIND plugin performs strict validation before SabreDAV starts streaming the multistatus response. If an unavailable mount would make the listing incomplete, the request now returns 503 Service Unavailable.

Validation

The original and fixed behavior were reproduced using a live SMB external-storage backend:

• Unpatched server: returned 207 while omitting the unavailable mount
• Fixed server: returned 503 without emitting an incomplete multistatus response
• A Nextcloud desktop client retained its local file during the outage
• Synchronization completed successfully after the backend recovered

The following checks passed:

• Full SQLite suite: 18,309 tests and 73,997 assertions; 128 skipped
• Common external-storage suite: 288 tests and 969 assertions
• SMB backend suite: 92 tests and 330 assertions
• Focused filesystem and DAV unit tests
• PHP lint
• Coding-style checks
• Psalm

TODO

• Review upstream CI results
• Decide whether a stable-branch backport should be requested

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes — not applicable; no front-end changes
• Documentation (manuals or wiki) has been updated or is not required — no user-facing documentation changes required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

Codex using GPT-5.6 sol assisted with issue research, code analysis, implementation, testing, environment setup, reproduction, and validation. The commit records this with an Assisted-by: Codex:GPT-5 trailer.

[CarlSchwan]

Could you try #63435 if this also fixes your issue? It's quite a bit simpler

[gitedmond]

Could you try #63435 if this also fixes your issue? It's quite a bit simpler

The approach in #63435 is much simpler and cleanly fixes the late 404 case. I tested both PR heads using a Depth: 1 PROPFIND request with an unavailable child mount. #63435 still returned 207, while #63169 returned 503.

It looks like getNodeForPath() validates the requested parent, but the unavailable child mount can still be silently omitted during directory enumeration. So it does not appear to cover the full incomplete-listing case from #63117. That said, if you think the narrower fix in #63435 is sufficient, I’m happy to defer to your judgment.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)