# Changelog

All notable changes to the Linux client since the 1.0.0 release. Format follows
[Keep a Changelog](https://keepachangelog.com/1.1.0/); versions follow semver, and every
release is tagged `vX.Y.Z` with `Cargo.toml` and `packaging/PKGBUILD` in agreement.

`Schema:` lines record the SQLite `SCHEMA_VERSION` (`pdfs-core/src/db/migrations.rs`) a
release ships. Migrations are forward-only — a database written by a newer client is a hard
refuse-to-open, not a downgrade, so rolling back a release means restoring the cache from
scratch (user data in `staging/` and `recovery/` is never touched by this).

## [1.8.1] — 2026-08-16

Some files read short through the mount and reported success — an application got a truncated
copy with nothing anywhere saying so (`docs/BUGS.md` B84). Found because GNOME's file indexer
kept complaining that PNGs under `~/ProtonDrive/Pictures` were corrupt; it was right. The rest
of this release is the long-standing architectural backlog from the July concurrency audits
(B25, B32, B39, B40, B43, B44), each verified against the current code before being fixed.
Schema: **28** — migration V28 adds `sync_entry.local_mtime_ns`.

### Fixed
- A read no longer trusts a revision whose recorded block sizes disagree with the file's size.
  Such a file leaves the block/range path entirely: it is fetched through the whole-file,
  manifest-verified download — the same path `pdfs pin` uses, and the reason pinning was the
  workaround — and served from the resulting cached blob. One download per file however many
  reads discover the problem at once, and files above 512 MiB fail `EIO` with a note to pin
  them rather than pulling down gigabytes for one read.
- A block that comes back shorter than the file's size implies is never served, cached or kept
  in memory. Assembling a read out of short blocks is what quietly produced the truncation:
  the missing bytes were simply not appended, the kernel handed userspace a short read, and
  every tool reads a short read as end-of-file.
- A synced folder no longer reports the same deletion as an error on every pass. Deleting a
  local file that something else had already deleted counted as a failure, which kept its
  baseline and made the next pass try again — forever. A path that is already gone is the
  state the sync pass wanted (`docs/BUGS.md` B42).
- A mirror folder no longer misses an edit made in the same second as its last sync. Change
  detection compared whole seconds, so rewriting a file in place without changing its length
  read as "unchanged" and never uploaded — the remote silently stayed behind until something
  else about the file moved. Baselines now record the modification time to nanoseconds
  (`docs/BUGS.md` B25).
- A sync download no longer overwrites an edit that finished while it was running. The
  destination is re-checked in the last moment before the download is published, and a local
  file that has moved on since the pass planned for it is kept as a conflict copy — the same
  resolution a both-sides-changed conflict gets (`docs/BUGS.md` B39).
- An upload interrupted by a writer no longer reports itself as synchronized. The baseline now
  records the content that actually went up rather than whatever is on disk when the transfer
  ends, so a revision torn by a concurrent write is replaced by a clean one on the next pass
  instead of standing as the file's content on Drive (`docs/BUGS.md` B40).
- Listing a directory that changes while it is being read no longer skips or repeats entries.
  `readdir` resumed by index into a listing rebuilt on every call, so a create or a trash
  between two pages shifted everything after it. The listing is now frozen for the life of the
  directory handle (`docs/BUGS.md` B43).
- Opening a file for writing while a previous close is still publishing no longer discards that
  close's revision. The base is re-checked at the moment the write handle is installed, rather
  than trusted across a copy that can be the size of the whole file (`docs/BUGS.md` B32).
- Unmounting now stops and joins the daemon's background workers instead of leaving them
  running. The drain, sync engine, conflict sweep, online probe, local indexer and control
  listener share a stop signal and interruptible waits, so an in-process remount no longer
  starts a second set on top of the first (`docs/BUGS.md` B44).

### Notes
- The size `stat` reports was always the correct one; it is the reader's belief about where
  blocks end that was wrong, so nothing about reported sizes changes.
- Verified live on the affected account: four multi-block PNGs that had been reading short now
  deliver their full size, and the journal shows each one repaired. The diagnostics also
  answered the open question, and not as expected — the revision metadata is fine; those files
  simply do not have 4 MiB blocks, and this client assumes they do. Filed as `docs/BUGS.md`
  B85. Until that is fixed, a file with non-4-MiB blocks is downloaded whole on its first read.
- Migration V28's new column is nullable rather than converted from the existing seconds. A
  baseline row written before this release has no sub-second time to recover, and inventing
  zero for it would make every already-synced file compare as changed and re-upload an entire
  mirror on first start; `NULL` keeps those rows comparing exactly as they did, and each gains
  a real value the next time its path syncs.
- Three audit entries closed without a code change, having been fixed already or being correct
  as they stand: sync-folder removal is serialized against reconciliation (B41), the drain's
  database contention was removed by the read-only connection pool and the claim column (B30),
  and the refusals for symlinks, hard links, device nodes and `chmod` are deliberate — Drive
  cannot represent them, and a local-only representation no other Proton client can read would
  be worse than a clean refusal (B31).
- Six of this release's fixes were then driven live against the installed 1.8.1 on a real
  account: the same-second edit uploads (B25), three rapid rewrites of a 64 MiB file publish the
  third one byte for byte (B32), a write racing a download survives as a conflict copy (B39), an
  upload torn by a concurrent write heals itself on the following pass (B40), a `getdents64`
  walk with a 160-byte buffer against a directory mutated between pages returns every entry
  exactly once (B43), and a restart of a daemon with six mounts and a busy drain stops in 110 ms
  and comes back at the same thread count (B44). B42 could not be driven from a single machine —
  see B86 below.
- One new bug came out of the verification: an on-demand mount serves a folder listing that
  predates the sync engine's own uploads, so files the mirror pass created are invisible until
  the folder is switched back (`docs/BUGS.md` B86). Nothing is lost — they are on the server and
  come back on the next mirror pass — but they cannot be seen or named while the folder is
  on-demand, which is also what blocks B42's live verification.

## [1.8.0] — 2026-08-16

A queued write whose node had left the local tree was retried every five seconds forever and
counted as an ordinary pending upload — 28 of them, holding 18.4 GiB, had been doing that for
30 days on the machine that found it (`docs/BUGS.md` B83). Schema: 27 — migration V27 adds
`pending_op.access_deferred_since`.

### Fixed
- The drain no longer reads "I have never heard of this node" as "you may not write this
  node". A missing authority is now resolved against the remote: the node is re-interned if
  it is still there, and reported as a real failure if it is gone. Ops that had been stuck
  invisibly for weeks now say what is wrong with them on the first pass.
- A create or mkdir resolves its *parent* as the authority, so the refetch asks about the
  folder rather than the node it has not made yet.

### Added
- Access deferrals are bounded. A deferral still costs no attempt and records no error for
  the first five minutes — the case it exists for is a share downgraded mid-queue and undone
  a moment later — but past that window each recheck records a failure, so the op enters the
  ordinary backoff and appears in `failing_ops` and the `pdfs status` error text like any
  other stuck operation. The first deferral of a run is logged at `warn` rather than `debug`.

### Notes
- No staged data is touched by any of this. A reported failure keeps its `pending_op` row and
  its staged blob exactly as before; the change is in what the user is told, and in the queue
  no longer waiting on a permission change that was never coming.

## [1.7.1] — 2026-08-16

Write-back throughput follow-up to 1.7.0, same audit
(`docs/plans/audit-2026-08-15-perf-locks.md`). Schema: 26 — migration V26 adds
`pending_op.claimed_at`.

### Added
- Parallel write-back drain: three workers share the queue through a `pending_op.claimed_at`
  claim column (migration V26), so a large upload no longer holds every queued rename, trash
  and small write behind it. Ordering is preserved per node — the claim query never offers
  two workers ops for the same uid — and claims left by a crashed run are cleared at open.
- An upload already on the wire is cancelled when a newer write, a trash or a discard
  supersedes it, instead of spending the uplink on a revision the next operation replaces.

### Changed
- The revision debounce is adaptive: it widens toward how long that node's last upload
  actually took (bounded to 2–60 s), so a file saved faster than it can be sent supersedes
  in the queue rather than mid-upload.
- Workspace deps bumped to `proton-sdk` / `proton-drive-rs` 0.6.0.

## [1.7.0] — 2026-08-16

Performance and robustness pass over the mount, from the architecture audit in
`docs/plans/audit-2026-08-15-perf-locks.md`. Schema: 25.

### Added
- Sequential-read prefetch (`Core::prefetch_ahead`): per-file sequential detection, depth
  doubling 2→8, reset to 0 after a seek, skipping blocks already cached, and bounded by its
  own permit budget so it can never queue ahead of a demand read.
- Single-flight block fetching (`BlockFlight`) keyed on `(uid, mtime, size, block)`, so a
  demand read, kernel read-ahead and prefetch of the same block share one download+decrypt.
- In-memory block LRU (`BlockRing`) in front of *both* block paths; a block read off disk is
  promoted into it, so the following ~31 kernel reads of that 4 MiB block cost nothing.
- Read-only SQLite connection pool (`ReadPool` / `Db::read`) with every `SELECT`-only method
  routed at it, so a read no longer waits on the write connection.
- `nodes.path` persisted and backfilled, replacing the recursive `path_of` walk.
- Single-writer `flock` on the database; a `SQLITE_CORRUPT`/`NOTADB` file is quarantined as
  `cache.db.corrupt-<ts>` (WAL sidecars too) and rebuilt rather than failing the mount.
- `VACUUM` and the deep `integrity_check` now ack immediately and run as background jobs;
  `pdfs doctor` polls for the verdict.
- Staging reconcile at mount: staged blobs no queued operation refers to are re-queued, or
  named in the log when they cannot be addressed.
- Queue/staging visibility — `Status` gained `parked_uploads`, `failing_ops`,
  `failing_error`, `staged_bytes`, `staged_oldest_secs`; `pdfs status` prints them when
  non-zero.
- `statfs` implemented against the account quota; FUSE `init` negotiates `max_readahead`,
  `max_background`, `PARALLEL_DIROPS` and `CACHE_SYMLINKS`; `blksize` raised to 1 MiB.

### Changed
- `State` no longer writes to SQLite under the inode lock — mutations queue into an outbox
  applied after the lock is released, so interning a 5000-child listing no longer commits a
  transaction with the whole mount frozen.
- Re-listing an unchanged folder no longer touches its subtree; when a subtree really moved,
  one recursive walk carries both the new path and the inherited trashed flag.
- `release(2)` no longer gap-fills from the network: it stages an incomplete blob from local
  caches only and the drain thread finishes it off the dispatch loop.
- A partial write over an undrained one is merged instead of refused.
- Size-upgrade waiters park on a queue instead of occupying a worker thread, capped at 8
  folders in flight; past the cap `stat` answers provisionally.
- Block-cache disk writes moved off the read's critical path; no more fsync per cached block.
- Cache LRU touches buffered in memory and flushed in one transaction.
- Search: sync-folder list and pin lookups hoisted out of the per-hit loop.
- SQLite tuned (`cache_size`, `mmap_size`, `temp_store=MEMORY`, `wal_autocheckpoint`) and
  three new indexes added.
- Mount registry lock released before FUSE teardown/join; kernel notifications batched under
  the state lock and flushed after it.

### Fixed
- **Data loss:** `ENOSPC` is now propagated from `write`/`fsync`/staging instead of being
  swallowed, with emergency eviction wired up and scratch marked durable before any staging
  error; a failed `record_pending_write` fails `release` rather than dropping the write.
- **Data loss:** the conflict sweep no longer discards queued operations after the trash
  round trip.
- **Data loss:** `rescue_scratch` moves a blob with an unreadable sidecar to `recovery/`
  unaccompanied instead of fabricating a sidecar for it.
- Own-sealed revisions are persisted (7-day TTL), so a restart no longer reopens the
  transient-download fork window fixed in 1.1.0.
- Depth-capped `is_pinned` (cycle-safe), daemon write timeout, and every client-supplied
  `limit` clamped.
- `recover_fsynced_writes` no longer scans the recovery directory on every idle pass.

## [1.6.0] — 2026-08-12

Search-index correctness and ranking (`docs/plans/search-index.md`). Schema: 21 —
migration V21 rebuilds `nodes_fts`.

### Fixed
- **B80** — 29% of the account was missing from the search index. `node_is_indexable_tx`
  required a null-parent ancestor, which only the My Files root has, so every node under a
  device folder was dropped from `nodes_fts` on its first upsert after the v16 backfill
  (2,705 of 9,252 nodes on the account this was diagnosed against). The rule now matches the
  backfill, migration V21 replays it, nodes under a trashed folder stay out, and the walk is
  depth-capped.
- **B81** — the prompt labelled every Drive hit "My files", including device folders; pin
  rows also took `is_dir` from `Pin::recursive`.
- **B82** — a `parent_uid` cycle hung the daemon on any short search: the recursive CTEs in
  `path_of` and the pin walk use `UNION ALL`, which does not deduplicate. `path_of` is now
  depth-capped at 256 and returns the truncated path.

### Changed
- Local search ranking: whole-query prefix matches get their own lane (newest first) ahead
  of trigram rank, which on a home directory full of dependency trees was burying the
  obvious answer — 73% of the 500 best-ranked candidates for "test" came from one Go module
  cache. The single-character lane, which recovers a typo that destroys every trigram, stays
  behind it.

## [1.5.0] — 2026-08-11

Schema: 20.

### Added
- **`pdfs-prompt --dmenu`** — the same search through an external dmenu-style launcher
  (fuzzel, rofi, wofi, tofi, bemenu, dmenu) instead of the built-in GTK HUD, so the prompt
  matches a tiling-WM desktop. A launcher filters a fixed list rather than re-querying per
  keystroke, so searching is a two-step loop; `--query` skips the first step, fuzzel and rofi
  get file-type icons. Configurable as `"prompt": { "mode": "dmenu", "menu": [...] }`, with
  `--gtk` overriding for one invocation.
- **Configurable open-with rules** (`pdfs-core/src/opener.rs`): an ordered list of name/class
  patterns in `config.json` under `open_with`, each mapped to argv and optionally wrapped in
  a terminal, first match wins, falling back to `xdg-open`. Lets "open a text file" mean
  `nvim` in a terminal without breaking every graphical caller. Absent config reproduces the
  old behaviour exactly.

### Fixed
- The prompt and dmenu openers hand applications the cached file while matching rules
  against the *original* Drive filename, so e.g. `.md` files stop being routed by their
  cache-path extension.

## [1.4.0] — 2026-08-10

Schema: 20.

### Added
- **File version history** (`pdfs-fuse/src/revisions.rs` + a GTK versions dialog): list a
  file's revisions, restore one, delete one, or write an old one out to a local path. A
  restore re-points the file server-side, so no content crosses the wire and nothing enters
  the drain queue; the daemon drops its cached content and repopulates on the next read.
- **Persistent SDK entity cache** (`pdfs-core/src/sdkcache.rs`): the SDK's decrypted node
  metadata now survives a daemon restart instead of re-walking the tree. It lives in its own
  `sdk_cache.db`, deliberately off the daemon's hot `cache.db` mutex, holds no key material,
  needs no migrations, and is cleared on logout.
- Per-node outcomes for batch operations (`pdfs-core/src/batch.rs`): `trash`/`restore`/
  `delete`/`move` report one result per node, so a node the server rejects no longer fails
  the whole batch.
- Photo viewer page in the GUI and richer photo metadata in the details pane.

### Changed
- SDK telemetry routed into `tracing`, so its transfer/block-storage/request spans land in
  the daemon log instead of a no-op sink.
- A file that fits in one block uploads as a single atomic request rather than the
  draft/block/commit sequence.

## [1.3.0] — 2026-07-31

Schema: 19.

### Added
- **Photo albums** — `PhotoAlbums` / `AlbumPhotos` control requests, daemon-side `albums.rs`
  and a GUI albums page (the former gallery view, renamed). Albums other people share with
  you are included; their photos are persisted per album because a shared album's photos
  never appear in your own timeline. Served stale-while-refreshing like the timeline.
- **GUI "Locations" page** — one row per mount spec: the primary `~/ProtonDrive` mount
  alongside every folder this computer backs up, mirrored or on-demand. Called *Locations*
  rather than *Mounts* because a mirror folder is a plain directory with no FUSE session.
  It absorbs the old Computers page's actions and the mountpoint chooser from Settings.
- `role` on shared-node metadata (`viewer`/`editor`/`admin`), defaulted for wire-compat with
  older clients and daemons.
- FUSE acceptance coverage for the permission-based mounts.

## [1.2.1] — 2026-07-31

Schema: 18.

### Fixed
- Migration bug that could leave the `ProtonDrive` mount unwritable after upgrade.
- Permission error on on-demand mounts.
- B78.

### Changed
- Release pipeline: `.deb` signing added and `.rpm` signing fixed.

## [1.2.0] — 2026-07-29

Sharing and multi-mount release. Schema: 18.

### Added
- **Shared with me**: shares others sent you are listed, verified and mountable, including on
  the primary mount.
  They appear under a synthetic `Shared with me` directory on a virtual volume
  (`pdfs-fuse/src/virtual.rs`), with name collisions and over-long components resolved by
  its own naming rules.
- Per-share access model (`db/share_access.rs`): the effective role of each shared root is
  persisted and kept resident in mount state, so interning an inode never costs a query. The
  database stays the restart/offline authority — every role change is written through before
  the cache updates. A share you cannot write is presented POSIX read-only.
- Unified location model (`pdfs-core/src/mounts.rs`, `db/mounts.rs`): one presentation shape
  for every local Proton Drive location, joining device sync state with a new `mount` table.
  `MountMode` is `Mirror` (full local copy, reconciled both ways) or `OnDemand` (FUSE session
  fetching on access), with an `Unknown` fallback so a mode written by a newer client does
  not break an older one.

## [1.1.1] — 2026-07-27

Schema: 16.

### Fixed
- Trash refresh did not pull updates.
- Packaging: `PKGBUILD` was left at 1.1.0 by the 1.1.1 version bump, failing the release
  workflow's tag/manifest/PKGBUILD agreement check.

## [1.1.0] — 2026-07-26

Conflict-handling and concurrency release. Schema: 16.

### Added
- Conflict sweep (`pdfs-fuse/src/sweep.rs`, 5-minute cadence): removes conflict copies proven
  identical by size + `content_sha1`, surfaces divergent ones once as an activity entry, and
  never removes what it cannot prove.
- Sweep mode and `.pdfsignore`-driven conflict handling; ignore rules are rebuilt per sync
  pass so edits take effect without a restart.
- Substantially extended FUSE acceptance suite.

### Fixed
- **B69** — spurious `(sync-conflict)` copies. Revision identity now uses the server's
  `revision_id` rather than `(mtime, size)`, which the server re-stamps on seal; the planner
  gained `AdoptBaseline` so an equal-size no-baseline pair is recorded instead of forked on
  first reconcile.
- **B70** — browser downloads into an on-demand mount had their in-flight temporaries sealed
  as canonical revisions. Transient names are recognised and held until the name is finalized.
- Assorted race conditions and concurrency bugs on the write/drain paths.

### Changed
- Workspace deps bumped to `proton-sdk` / `proton-drive-rs` 0.2.2.

## [1.0.0] — 2026-07-22

First stable release: FUSE files-on-demand mount, sync daemon under `proton-drive.service`,
`pdfs` CLI and the GTK4 app, on top of the pure-Rust Proton Drive SDK. Schema: 16.

### Fixed
- The outstanding FUSE defects tracked in `docs/BUGS.md`, plus a truncate defect, validated
  by a new POSIX compliance suite for the filesystem.

[1.7.1]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.7.1
[1.7.0]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.7.0
[1.6.0]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.6.0
[1.5.0]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.5.0
[1.4.0]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.4.0
[1.3.0]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.3.0
[1.2.1]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.2.1
[1.2.0]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.2.0
[1.1.1]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.1.1
[1.1.0]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.1.0
[1.0.0]: https://github.com/narrrl/proton-drive-linux/releases/tag/v1.0.0