feat: upload owner-private files through core fragment storage

[erikleblansch]

Verified owner-private upload/recovery milestone — 2026-10-04

The shared-core original run 37218270756 passed at exact Cloud ffdcfaa15cdd2a029dae545904b0a58603da4e17 and core 929c2ff909f4e9704046459e0434006397dc9110. Original Files/Uppy upload, owner encryption, actual protected fragment deposits, durable publication, restart and two native verified downloads all execute. The synthetic source and local ciphertexts are unavailable and provider A is stopped during recovery. Sixteen baseline/upload fragment copies keep their exact charges through reads, then retire to zero provider usage. Private service/browser/topology cleanup passes and disposable guest-root network state is unchanged.

Original ZIP: 45 files, SHA-256 0f4da4f71ed7c0ddbf58668c6982f2a0d6e1d510789c21e8293b815c8474e11c. Root and independent capture review verified the source-bound report; reconstruction from the original phase files also passes. Earlier failed trials remain failed.

Integration head ee5e93f62782de92008026fae3173b8f18b10419 preserves all tested product/fixture bytes, merges only the existing main banner and updates four documentation pages. No new model, policy, resource, deadline or source-pin changes.

Remaining scope is explicit: new owner-private files only; imported files remain read-only. No overwrite, folder creation, rename/delete UI, shared accounts, sharing, general synchronization, second-device recovery or automatic renewal/repair. Owner keys/catalogs/journals remain local. This is not a completed always-available OpenCloud service.

---

Supervised shutdown candidate — core 17e1bf3a / Cloud ffdcfaa1

Exact source: core 17e1bf3aa4cf4528dfcc8405db7e6e2c8b5cdfe4 (tree cfd875a647bf98fb35355630bd7f989ac3565f8f), Cloud ffdcfaa15cdd2a029dae545904b0a58603da4e17 (tree 23e3ebf2e228a734d41d55031521a47a33678a98). This is a reviewed candidate, not a live upload/recovery PASS. The single exact-source run 37210057593, attempt 1 / job 111459244322, is terminal FAILED before UI execution: FRAGMENTS_ROUTE_UNAVAILABLE at private-storage-fragments-prepare, 24 attempts/23 retries, final CONNECT_REJECTED / NO_ELIGIBLE_PATHS, zero redraws/path polls. The supervised-lock fix was not reached by this trial. Provisioning passed; all eight private-cleanup flags passed and zero owned objects remained. Guest-root snapshots match (c1b0f78b5a02c15cb451aa087ea0b680e4ee6a53a09b67a3f4026c6ba1d63fe3), not separate outer-host proof. Original ZIP SHA-256 21fd3819a2e9e4080390fc515c70a42c72e7d5fd67ad6ef1101aa923c73e4519; original log SHA-256 7799de27d7a9d7374d3cfcf742cdbbd3d4f336c545b371b15589954933a97236. No automatic rerun or acceptance/resource/deadline increase is authorized.

Original run 37207919255 is FAILED. Selection connected after 16 attempts/15 retries. The parent retained original_ui_upload, child stage cleanup and no closed UI-failure record. The pinned child enters that stage only after its success/browser/profile-cleanup path, but its full receipt and exact later parent failure were not retained. Independent object/charge and restarted-download checks are therefore not established. Private cleanup passed, zero owned objects remained, and guest-root network snapshots matched (c27ed94d831d21b4d47a1aff168f9b9a22d9a153e586ff1c024d56367361be97); this is not separate outer-host proof. Original ZIP SHA-256 9995515c4b1120b30b3dd2bc2317ecb6c6018b76c58c97b848cb8728d8d3da49; original job-log SHA-256 e69ac4cc153cdf2a379c63968c3bd0ba832fab63e441e7d2267a509ff820e403.

A real Node-owner/Python-lock process-group regression independently reproduced premature lock termination during SIGTERM shutdown. The helper now retains its lock across TERM/INT/HUP until the owner's control pipe closes after outstanding work is joined. Forced SIGKILL still fails acknowledgement; the existing bounded escalation remains. This reproduced defect is not retroactively asserted as the original run's unretained exact cause. The core now records a closed parent phase and fixed post-UI stages without exporting raw private data.

Verification: two actual Python lock/EOF/contention/forced-kill tests and four targeted Node owner/restart/cancel checks pass; 11 core upload, 13 provisioning and 6 historical read-only tests pass. All 27 inventory entries match the committed Cloud source; shell syntax and diff checks pass. Local storage doubles do not establish live peer proof. Original native upload, exactly one logical object, retained manifests/leases, fourteen physical copies, actual provider charges, restarted downloads, retirement and cleanup remain required and unchanged.

---

Native post-upload drive refresh — core 21f5cfc7 / Cloud 0d483f5c

The exact-source run 37207919255 is terminal FAILED, as detailed above. Original OpenCloud Files awaits Graph getDrive before refreshing its DAV list. The pinned SDK uses /graph/v1.0/drives/{id}, which the adapter did not recognize. The correction adds only that authenticated exact-root GET alias; v1.0 accounts, collections, permissions and writes remain unavailable. No client-side refresh bypass, added retry, changed timer or weakened acceptance gate.

Both the real HTTP regression and actual pinned SDK reproduced the 404 before this fix. Twenty-one DAV checks and one actual SDK/GPG/HTTP upload-refresh-list/read test pass (storage in that local test remains synthetic). Twenty-eight core fixture/provisioning checks pass; all 27 source hashes match the committed Cloud revision. Independent review found no blocker. The original real file-input action, unique object, retained manifest/leases, fourteen physical copies, actual charges, restarted downloads, retirement and cleanup are still required in the new live trial.

Original retry-aware trial — upload acknowledged, live listing failed

Run 37206160237, core e1cb044c7086f97c2a25991a22ac2ae2f7aeef22 / Cloud b1a425964d725472e79b6f0f05ce96e5953cadcf, is FAILED. Its two completed native PUT observations were [0,201]; the bounded native retry receipt passed, then original_ui_upload/upload_commit timed out waiting for the uploaded file in the Files listing. Status 0 records no HTTP response, not a known server error. Independent object/charge, restarted-download and retirement checks were not reached. The browser's Graph response was not retained, so the independently reproduced API gap is not retrospective proof of that run's exact HTTP failure.

All private cleanup observations passed; final cleanup left zero owned objects and matching guest-root network snapshots, not separate outer-host proof. Original ZIP SHA-256 f3501056fbe9323314d34ba1bfee24ab4682f62c193de40684e19831b00b922c; original job log SHA-256 d0e0ecd7b88fafacf0897023ded71b01705f7ecf572d3a29c210bca711a81708.

---

Original native-upload trial — failed at single-request assertion

Run 37204384631, core e57102a26c4a1d0bbda8062459f6f31f6b2b2a9c / Cloud 32836543d950081a2b1505ebde117d8f9db35b82, reached a connected route after 23 attempts/22 retries. The original file-input action produced closed observations {puts:2, completed:2, created:1, last_status:201}. The fixture then failed its puts===1 && created===1 assertion before listing/reload/recovery and final independent charge checks. The first HTTP status was not retained; native retry is possible, but its cause is not proven. This remains FAILED, not completed upload/recovery evidence.

Pinned Uppy already allows three retries. The next fixture correction will account for those existing bounded native retries while requiring exactly one committed creation and retaining independent object/manifest, physical-copy, charge, restart/download, retirement and cleanup checks. No extra retries, time or storage budget will be added.

Original cleanup passed with zero owned objects and matching guest-root network snapshots, not separate outer-host proof. Artifact ZIP SHA-256 03ec315aeb2f256db49e53176853a51159c6a5a2a5747eb595872260e9d785c5; original job-log SHA-256 be006200a4b6b2be6b3509fd33589aaeebe6c248c9446f3db8057b82404fde66.

---

Change

Adds an explicitly configured owner-private upload space alongside unchanged read-only imports. The original OpenCloud Files/Uppy upload action uses authenticated loopback DAV PUT; files are privately staged and encrypted using the existing GPG helper, then sent through the existing core fragment create/deposit interface. A new file becomes visible only after confirmed redundant storage and durable encrypted-catalog publication.

Core retains placement, uniform redundancy, grants and accounting. There is no second storage ledger or application-specific copy-count option. New owner files carry distinct authenticated provenance; they do not impersonate imported OpenCloud account rights.

Working boundaries

• New files only; imported spaces remain read-only. No overwrite, folder creation, sharing, original-account writes or upstream fallback.
• Incomplete uploads retain the same journal/ciphertext. Explicit retry requires the same name and exact content; restart and repeated restore do not consume stored data.
• READY publication is atomic after fsync; the targeted partial-write regression fails on the old path and passes on this implementation.
• Original Files upload control is enabled only in explicit upload mode; read-only mode is unchanged.
• Bounded owner workspace, serialized uploads, ciphertext/read budgets, original scope and private cleanup remain enforced.

Verification

Focused real HTTP/GPG, encrypted catalog, restart/retry, cancellation and provenance checks pass using an explicit in-memory core-provider fixture. Actual pinned OpenCloud Web8 SDK PUT/list/read/overwrite-refusal checks pass against that fixture. The source patch applies to the exact pinned upstream source. Six pure native-driver boundary checks and three asset checks pass. Independent product review found and fixed the READY interruption issue.

The new guest-only driver exercises the original Files file input/Uppy action and a fresh browser's two verified downloads. It is prepared, not yet a native browser/live-peer upload PASS. The separate core cloud-private-upload scenario now pins exact Cloud source 3e3d6587012ed46d200218e4447506300f8a4f18.

The previous live trial reached UI provisioning but the strict builder rejected noncanonical patch bytes. This revision fixes patch metadata/order/context prefixes, with all eight postimage files byte-identical and the builder guard unchanged. Two regressions execute that actual guard: canonical passes; applicable but noncanonical still fails. No upload/recovery PASS is inferred from this source-admission fix.

Remaining scope

The original server-off read-only proof remains valid only for its original sources. Full server-independent OpenCloud accounts, synchronization, sharing, cross-device key recovery, automatic repair and native upload evidence remain unfinished. Owner keys/catalogs/journals still live locally. Setup and precise limitations: docs/OWNER_UPLOADS.md.