mirror of
https://github.com/narrrl/proton-drive-linux.git
synced 2026-11-04 08:56:59 +01:00
nvrl
a6f36d56f3
A change Drive refuses because the storage is full, access was taken away, its folder is gone, a folder limit is reached or the change was rejected used to look like any other failure until six attempts had passed. The drain now sorts the refusal into an issue and stores it on the queued op (schema 38), so it needs attention at once in the app, tray and CLI. The change stays queued and is retried; nothing is deleted. The queue listing carries the issue and whether the op has file content. ExportPendingOp copies that content to a new file: the Sync page offers it as an Export button next to each issue, and the CLI as `pdfs sync export <id> <dest>`. `pdfs sync issues` lists what needs attention, and `pdfs sync queue` shows the issue per change. docs/MILESTONE-3.0.0-STATUS.md tracks what is left for 3.0.0.
2.9 KiB
2.9 KiB
3.0.0: what is done and what is left
Tracks docs/MILESTONE-3.0.0.md. Update it with every commit that moves a phase.
Done
- Phase 0: fake Drive, simulation runs, CI job (2.9.0).
- Phase 1: queued-op preconditions and own sealed revisions in the database (2.9.0).
- Phase 2: local ids, inode = local id, one tree for every mount (2.10.0).
- Phase 3, first part: mkdir, create, rename, unlink and rmdir on the mount are recorded
locally and sent from the queue;
"local_first": falsebrings back the old path (5e0f30c). - Fixes from the simulation and account runs since then: B141 to B147.
- Sync issues, first cut (§6.2): refusals sorted into issues, shown at once in the app,
tray and CLI; Export button and
pdfs sync export;pdfs sync issues.
Phase 3: left for 3.0.0
- Sync issues (§6.2): first cut done.
- The drain sorts a refusal from Drive into an issue kind (quota, access, missing, limit, rejected) and stores it on the queued op (schema 38).
- An op with an issue counts as "needs attention" at once, not after six failures.
- The queue listing carries the issue kind and whether its content can be exported.
- Export a queued file's content (control request,
pdfs sync export). pdfs sync issues, and the issue shown inpdfs sync queue.- The app's Sync page shows each issue with what the user can do; Export and Retry buttons; translated in every catalog.
- Discard an issue on purpose (after export, or for a change with no content), and undo the local change it stood for. Not in the first cut.
- Show the issue on the node itself (file browser emblem or status). Not in the first cut.
- Planner and executor (§5.4, §5.5): ops keyed by local id; remove
mint_local_uid,finish_createandadopt_real_uid; a landing create setsremote_uidon its row. - Speed (§7): run independent ops in parallel, batch trashes and moves; measure 1,000 files and 100 folders on Wi-Fi against LAN (target: within 10 %).
- Done-when checks:
- Simulation passes on the Wi-Fi profile.
- Known-bug list in
sim/run.rsis empty: B125 and B130 open; B129 and B132 fixed but unconfirmed. - A clean account run. The last one (2026-10-04) failed on B70 (fixed as B145) and mirror/mirror "busy syncing" (the script now retries); not confirmed yet.
- Release: the 2.9.0 and 2.10.0 tags still wait for the user's go-ahead.
After 3.0.0
- Remove the old online path in
filesystem.rsand thelocal_firstswitch (the release after 3.0.0). - Phase 4: one applier for remote changes.
- Phase 5: mirror folders on the same planner and executor.
- Any time:
Sizeand block geometry as types; aDeadlineon every remote call. - Open questions in §12 of the milestone.
PLAN.md: the acceptance script notices network drops and reportsinterruptedinstead of TIMEOUT.