Skip to content

fix(libsync): add OWNCLOUD_BULK_UPLOAD env override to force-disable bulk upload#10300

Open
mosandlt wants to merge 1 commit into
nextcloud:masterfrom
mosandlt:fix/bulkupload-env-override
Open

fix(libsync): add OWNCLOUD_BULK_UPLOAD env override to force-disable bulk upload#10300
mosandlt wants to merge 1 commit into
nextcloud:masterfrom
mosandlt:fix/bulkupload-env-override

Conversation

@mosandlt

@mosandlt mosandlt commented Jul 4, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds an OWNCLOUD_BULK_UPLOAD environment variable override to Capabilities::bulkUpload(), mirroring the existing OWNCLOUD_CHUNKING_NG pattern in the same file (src/libsync/capabilities.cpp).

Problem

Bulk upload (POST .../dav/bulk) is enabled automatically whenever the server advertises the dav.bulkupload capability, with no client-side way to opt out if that endpoint is broken or blocked somewhere in the network path (reverse proxy, WAF, CDN, etc).

Observed against a self-hosted Nextcloud instance where every single bulk-upload POST failed immediately with UnknownNetworkError, while regular per-file uploads (PropagateUploadFileNG) succeeded without issue. Because the failure is deterministic and the in-memory per-file bulk-upload blacklist does not survive across the --max-sync-retries internal restarts (let alone separate nextcloudcmd invocations from a cron/systemd timer), affected files never converge — the sync stays permanently red for every file it decides to bulk-upload, run after run, with no recovery path short of patching the client.

Fix

OWNCLOUD_BULK_UPLOAD=0 forces bulk upload off regardless of server capabilities (falls back to the normal single-file upload path). OWNCLOUD_BULK_UPLOAD=1 forces it on. Unset preserves current behavior exactly (server capability decides).

Verified locally: rebuilding nextcloudcmd/libnextcloudsync with this change and setting OWNCLOUD_BULK_UPLOAD=0 took a sync from a reproducible ~630-file failure batch (100% of that sync's bulk-upload attempts failing with UnknownNetworkError, identical set of files failing across 3 consecutive runs) down to a clean run with zero bulk-related errors, using the regular upload path instead.

Testing

  • Local dpkg-buildpackage build against Debian 12 (bookworm) package 3.7.3-1+deb12u2
  • Confirmed OWNCLOUD_BULK_UPLOAD=0 / =1 / unset all behave as expected against a real server
  • No existing tests cover Capabilities::bulkUpload(); behavior for the unset case is unchanged (same expression as before, now reached only after the two new early-return checks)

…bulk upload

Mirrors the existing OWNCLOUD_CHUNKING_NG override pattern in the same
file. Bulk upload (POST .../dav/bulk) is enabled automatically whenever
the server advertises the dav.bulkupload capability, with no
client-side way to opt out if that endpoint is broken or blocked
somewhere in the network path (reverse proxy, WAF, etc).

Observed against a self-hosted Nextcloud instance where every single
bulk-upload POST failed immediately with UnknownNetworkError, while
regular per-file uploads succeeded without issue. Because the failure
is deterministic and the client re-attempts bulk upload from scratch
on every sync invocation (the in-memory per-file blacklist does not
survive across the max-sync-retries restarts, let alone separate
nextcloudcmd invocations), affected files never converge and the sync
stays permanently red for that server.

Setting OWNCLOUD_BULK_UPLOAD=0 lets an operator route around a broken
bulk endpoint without needing a custom build, matching the escape hatch
already available for chunking via OWNCLOUD_CHUNKING_NG.

Signed-off-by: mosandlt <[email protected]>
@mosandlt mosandlt force-pushed the fix/bulkupload-env-override branch from 72ea360 to a061b60 Compare July 4, 2026 19:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant