What's new

Improved the mass-deletion review summary when many flat files are affected.

When the deletion guard pauses for a large number of files sitting at the top level of a folder, the review now groups them in an expandable "En el nivel raíz · N archivos" row that shows a preview of the first 15 files and a "y M más…" note — instead of a bare counter with no detail. Subfolder groups stay collapsed by count, and individual rows are only listed when the number of missing files is small.

This makes it clear what was removed without scrolling a hundreds-row list.

Validation

• 708 tests passed + 1 ignored, clippy and fmt clean.
• End-to-end: a 260-file flat deletion shows the preview in the review dialog.

What's new

Proactive desktop notification for the deletion guard (#203), ported from PyNextCloud-Sync 0.1.32.

When the deletion guard pauses synchronization on a mass local deletion, NextSync now raises a critical desktop notification with a "Review Now" button that opens the deletion review directly, even when the app runs only in the tray. Previously the mass deletion was only visible in the tray/UI and the user was never proactively alerted.

Details

• Critical-urgency desktop notification when the guard flags a mass deletion.
• "Review Now" action opens the deletion review (the window is presented and mapped first, so it works from the tray).
• A large deletion review summarizes by folder count instead of listing every file (for more than 50 files), keeping a few hundred flat files readable.
• Spanish/English copy for the new notification flow.

The deletion guard scope is unchanged: only local deletions before they reach the server pause for review; deletions from the server, web or mobile keep flowing through the engine.

Validation

• 708 tests passed + 1 ignored (known flaky login flow), clippy and fmt clean.
• End-to-end verified: notification raised and "Review Now" opened the review.

What's Changed

Tray icon stuck on cloud-sync forever (#197)

Since the ETag gate landed, the tray icon stayed on cloud-sync even when every folder was idle: the aggregate reported a queued folder that never ran (no nextcloudcmd process, ~0 CPU).

Root cause: SyncPermit::release() wakes exactly one waiter and assumes it will take the permit. A woken scheduler whose start() bails out through an early guard (leftover waiter with an empty queue, already running, paused, ...) swallowed the turn: the permit sat free while every other waiter slept forever. The ETag-skip made runs milliseconds long, turning a rare interleaving into a routine one.

Fix: start() now reports whether it ran, re-queued (waiting on the permit) or aborted; an aborted waiter passes the turn on to the next waiter. Regression test covers the exact double-waiter interleaving (red-green verified).

Full Changelog: v0.2.14...v0.2.16

Install (Arch/CachyOS)

curl -LO https://github.com/gnacho/nextsync/releases/download/v0.2.16/nextsync-0.2.16-1-x86_64.pkg.tar.zst
sudo pacman -U nextsync-0.2.16-1-x86_64.pkg.tar.zst

sha256: 2985f53985fd835fba68313067cffbba0f4c87d0675c3248d66b4b492140e6ba

What's Changed

The per-folder root ETag is persisted across restarts (#195)

The ETag gate (#189, v0.2.10) already skips the full nextcloudcmd reconciliation on the periodic interval when the remote tree is unchanged - but the ETag only lived in memory, so after a restart the first interval of every folder re-scanned the full tree even with zero remote changes.

Now the ETag is saved per folder in the app state directory (~/.local/state/nextsync/etags/, outside the synced folder) and re-seeded on startup. Consequence: after a launch, the first remote-interval run skips the reconciliation when nothing changed, instead of re-scanning (important on the large folders - Fotos ~65k files).

Best-effort persistence: a missing/stale value degrades to "changed", which reconciles - the safe direction.

Full Changelog: v0.2.12...v0.2.14

Install (Arch/CachyOS)

curl -LO https://github.com/gnacho/nextsync/releases/download/v0.2.14/nextsync-0.2.14-1-x86_64.pkg.tar.zst
sudo pacman -U nextsync-0.2.14-1-x86_64.pkg.tar.zst

sha256: 6b19870aaa70c769eb51c4ae9ce6fcae27637f642b06c8fe310b9e0c916fbe96

What's Changed

This release closes every open issue. Highlights:

Queue discipline (#181)

A folder no longer re-runs from its own engine-generated file events. nextcloudcmd writes its sync journal inside the synced folder, and that tree is inotify-watched; each run spawned local events that requeued the folder (8 engine runs in 27s - "the folder jumps"). Self-generated local feedback during a run/cooldown is now dropped: a folder only syncs again on a real change.

Setup wizard remote-folder picker (#147)

After login (browser or manual) the wizard clears the password field and keeps the secret in the keyring; the folder picker was reading the emptied field and opened with no list. It now resolves the credential from the keyring.

Intermittent GTK crash during sync (#153)

The Conflict / Recent / Deletion lists were emptied with unparent(), leaving ghost rows in the GtkListBox that later crashed GTK (SIGSEGV - the crash you had been seeing for weeks). They now use remove_all().

Mass-deletion review grouped by top-level folder (#182)

Instead of a flat list of up to 100 paths, a large cleanup (vendored SDK, virtualenvs, caches) is grouped by directory with a count and expandable rows, so what is about to be deleted is readable at a glance.

Flaky login-flow test fixed (#174)

The integration test server answers each request by URL instead of a positional sequence; verified 60/60 runs without the PollHttp 400 (was ~1/143).

#166 closed as superseded

Heavy-folder re-discovery is covered by the ETag gate (#189) + queue discipline (#181).

Full Changelog: v0.2.10...v0.2.12

Install (Arch/CachyOS)

curl -LO https://github.com/gnacho/nextsync/releases/download/v0.2.12/nextsync-0.2.12-1-x86_64.pkg.tar.zst
sudo pacman -U nextsync-0.2.12-1-x86_64.pkg.tar.zst

sha256: ae1c2596ffb47c639993b3271b9d643e3f569217f583eb9ca02c140178525efe

What's Changed

The periodic remote-interval poll is gated on a root ETag check (#189)

Previously every remote-interval poll (default 10 min) ran a full nextcloudcmd reconciliation of each folder, re-discovering the whole tree and emitting tens of thousands of progress events even when nothing changed on the server - the "it keeps syncing even though no files changed" symptom. On big folders (Fotos ~65k files, Mi Nube, Zbox) this was the dominant load.

Now, before reconciling on a purely periodic interval, the app does a cheap root ETag check (a single PROPFIND Depth:0 for <getetag/>); if the ETag is unchanged it skips the full reconciliation and the folder stays up to date. This mirrors the official client's RequestEtagJob/Folder::etagRetrieved.

• Manual, inotify, startup, push, resume and recovery runs still always reconcile - only the periodic interval benefits.
• If the ETag cannot be read (server unreachable / absent), the interval reconciles rather than skipping, so a real change is never missed.

Internal: NextcloudApi::root_etag, EtagProbe/ProductionEtagProbe (same injectable pattern as the #179 health probe).

Full Changelog: v0.2.8...v0.2.10

Install (Arch/CachyOS)

curl -LO https://github.com/gnacho/nextsync/releases/download/v0.2.10/nextsync-0.2.10-1-x86_64.pkg.tar.zst
sudo pacman -U nextsync-0.2.10-1-x86_64.pkg.tar.zst

sha256: 4dcd659cf1b995a4392cf6fd31fa910f7df9a1197acd20be7f9928a993592645

What's Changed

User-visible improvements (benchmarked against the official Nextcloud client)

A remote change now syncs only the folder that owns it (#183)
The push hint notify_file_id from the server is resolved against each folder's sync journal, and only the folder that actually contains the file is re-synced. Previously a single change re-scanned every folder of the account. If the server still sends a legacy notify_file (no id), the previous fan-out is kept for safety.

A folder that keeps failing backs off instead of hammering the server (#184)
After 3-4 consecutive failures it waits 10s, 5-6 waits 30s, and 7+ waits 60s before retrying (mirroring the official client). Cleared on the next successful sync.

The remote-interval poll is skipped while push is active (#185)
While the account's push channel is connected and delivering real-time changes, the periodic remote interval is skipped so it does not run a full reconciliation on top.

Push detects dead connections and caps auth retries (#186)
The push channel tracks connection activity: if the server goes silent for 75s it reconnects (no silent zombie). Also, after 3 failed push auth attempts it stops retrying in a loop and parks until the network or config is restored.

Internal

• New core/files_journal.rs: read-only lookup of the external sync-engine journal to resolve file ids per folder.
• rusqlite (bundled) added to read that journal.
• 685 tests, clippy clean, fmt applied.

Full Changelog: v0.2.6...v0.2.8

Install (Arch/CachyOS)

curl -LO https://github.com/gnacho/nextsync/releases/download/v0.2.8/nextsync-0.2.8-1-x86_64.pkg.tar.zst
sudo pacman -U nextsync-0.2.8-1-x86_64.pkg.tar.zst

sha256: 5d028faaff7dbae58fced79382e7acf5e37b15aa18fa570e2ac0b7b81fd75007

What's Changed

Account goes offline when the server is unreachable (#179)

A failing sync now triggers a quick health probe against the server. If the server does not respond (or returns a 5xx), the account is marked offline instead of showing "Connected" and retrying on every trigger.

• A folder fails -> probe the server; dead server -> NetworkError, no nextcloudcmd spawn
• Recovery probe every 30s detects the server returning and resumes syncing automatically
• An unreachable account stops holding the global sync permit, so healthy accounts keep syncing
• Folder row shows: "Synchronization blocked: the server is unreachable"

Full Changelog: v0.2.4...v0.2.6

Install (Arch/CachyOS)

curl -LO https://github.com/gnacho/nextsync/releases/download/v0.2.6/nextsync-0.2.6-1-x86_64.pkg.tar.zst
sudo pacman -U nextsync-0.2.6-1-x86_64.pkg.tar.zst

sha256: a91ecb56ac53b045726b7959f1dacf11761b6fe04a3fd5e6ec123df72661696a

What's Changed

Credential cache in memory (#178)

Account passwords are now cached in process memory: one Secret Service session negotiation per account per process instead of up to three per lookup on every folder sync (the pattern desktop clients like Iotas use).

• Lookups serve the cache first; keyring resolutions populate it
• Sign-in writes through, account removal evicts
• A sync run ending in authentication failure invalidates the cache so the next lookup re-reads the keyring after signing in again

Side effect: much less exposure to transient keyring locks mid-session.

Full Changelog: v0.2.2...v0.2.4

Install (Arch/CachyOS)

curl -LO https://github.com/gnacho/nextsync/releases/download/v0.2.4/nextsync-0.2.4-1-x86_64.pkg.tar.zst
sudo pacman -U nextsync-0.2.4-1-x86_64.pkg.tar.zst

sha256: 7908a3629d54a63a7fd5574d018bcb20af590bc9f832db24b884d1e47e130521

Release v0.2.2.

Fixed

• The queued-folder waiting message is coherent (issue #169): only the head of the queue names the folder it waits on; the rest show the generic wait.
• A transiently locked password keyring now recovers on its own (issue #170): a capped backoff retry re-reads the credentials and clears as soon as the Secret Service is ready, instead of staying locked until restart.

Gate: 667 passed + 1 ignored, clippy/fmt clean.