ods v0.3.5

Four defects with one shape: the tool reported success on a no-op. Each one
produced output a reader would read as healthy while nothing had happened.

Fixed

• A locally-created repo was auto-activated and then never backed up. Discovery
  deliberately scans the local project parent as well as the OneDrive one, so a repo
  created locally is found and activated before it exists on OneDrive — and then the
  run loop's vanished-side guard skipped it every cycle, because it could not tell
  "the OneDrive copy was DELETED" from "it has never existed yet". The repo was
  auto-activated and passed over, every 30 minutes, indefinitely. The guard now uses
  the baseline as the discriminator: no baseline means it has never synced, so it
  is seeded and pushed up; a baseline proves the copy once existed, so a genuinely
  vanished one is still protected and never mirrored as a deletion. Three repos on one
  machine had no OneDrive copy at all when this was found — one of them since 26 August.
• A skipped project was invisible in the run summary. Both skip paths continued
  before the tally, so a run that silently skipped three repos still reported
  ok=21 warn=4 and looked healthy. That is precisely why the defect above survived
  weeks of 30-minute cycles. Skips are now counted and reported, and the two reasons
  get deliberately different words: skipped (did not sync — no backup) can never
  merge into carried (fine, just next cycle).
• An interrupted bisync could wedge a pair permanently. ods never passed rclone's
  --max-lock, and rclone's default is 0 = never expire, so a lock left by a killed
  run never lapsed — one observed on another machine advertised an expiry in the year
  2226. Bounded now by bisync_max_lock_minutes (default 30; 0 keeps rclone's
  behaviour, and rclone's own 2-minute floor is respected).
• A destructive command accepted an id matching nothing and reported success.
  resolve_id refused an ambiguous id but returned an unmatched one verbatim, so
  ods forget tombstoned a junk id and exited 0 while the real project stayed active.
  The trigger was an unquoted Windows path in bash, which strips the backslashes.
  Unmatched ids are now refused for destructive commands, with an error naming the
  quoting cause; ods forget --force covers the legitimate case of retiring an id that
  genuinely no longer exists on this machine. forget now also prints what it did
  rather than only writing it to the log.

Changed

• tests/divergence.rs now builds a hermetic fixture (core.hooksPath plus
  init.templateDir=), so a machine-global git hook cannot take the suite down. An
  identity-checking pre-commit hook had begun refusing the fixture's own throwaway
  author, failing the integration test on completely unmodified code.

Full Changelog: v0.3.4...v0.3.5

ods v0.3.4

Fixed

• A stale .git lock wedged a repo out of sync indefinitely. The git-quiesce
  gate treated any *.lock under .git as an in-progress operation, so an
  abandoned lock — e.g. the 0-byte .git/objects/maintenance.lock a crashed
  git maintenance leaves at boot — deferred the repo every cycle, forever. A
  lock now gates only while it is fresh (stale_lock_seconds, default 300 s); an
  older one is treated as the crash artifact it is. This is the underlying cause
  of the claude-config deferral below.
• A recovered project stayed "needs attention" forever. Two defects in the
  defer path: update_defer_count only ever incremented deferred[id] (never
  reset on a clean cycle, so the count was a lifetime tally, not the "consecutive
  cycles" its escalation claimed), and reconcile never pruned deferred, so a
  counter for a vanished project never cleared. A run now resets the counter for
  every project that synced cleanly and prunes orphaned deferred keys;
  compare/maxDelete (user settings) are left intact. Deferrals now log their
  gate reason (onedrive-busy / git-active) so the escalation is diagnosable.
  Real trigger: a crashed git maintenance left a stale 0-byte
  .git/objects/maintenance.lock, which the git-quiesce gate reads as "git
  active" every cycle — Tools\claude-config had deferred 235 times.
• Panic on any path containing non-ASCII characters. paths::starts_with_ci
  sliced a &str using len() — a BYTE count — so whenever the prefix length
  landed inside a multi-byte character, the slice panicked with "byte index N is
  not a char boundary". ods add-watch into a Hebrew-named OneDrive folder hit
  it every time (the failure depended on the byte length of the local path, so it
  looked intermittent), and the GUI's add discovery root reached the same code
  with any non-ASCII folder. Prefixes are now compared as byte slices, which
  leaves ASCII behaviour unchanged.

Full Changelog: v0.3.3...v0.3.4

ods v0.3.3

Fixed

• ods update from a PowerShell 7 terminal. The updater it spawns is Windows
  PowerShell 5.1, which inherited pwsh 7's PSModulePath and then couldn't load
  Microsoft.PowerShell.Utility — so Get-FileHash went missing and the installer's
  checksum verify aborted the update. ods update now drops PSModulePath for the
  spawned process, so WinPS 5.1 rebuilds its own default module path.

Full Changelog: v0.3.2...v0.3.3

ods v0.3.2

Fixed

• install.ps1 no longer races the tray on redeploy. It stopped ods-gui.exe and
  copied immediately, but Stop-Process returns before Windows releases the exe's image
  lock, so the copy could fail "used by another process" — precisely the path ods update
  and any redeploy take, since the tray is running then. It now waits for the process to
  fully exit before copying.

Full Changelog: v0.3.1...v0.3.2

ods v0.3.1

Fixed

• install.ps1 -FromRelease / get.ps1 checksum verification. The SHA256 sidecar
  fetched via Invoke-WebRequest -UseBasicParsing arrives as a byte array (GitHub
  serves it as octet-stream), so the hash comparison ran on bytes and aborted every
  download with a false "checksum mismatch." Decode the sidecar to text before comparing.
  The v0.3.0 binaries were correct — only this client-side check was broken.

Full Changelog: v0.3.0...v0.3.1

ods v0.3.0

Added

• ods is now on PATH. install.ps1 adds %LOCALAPPDATA%\ods to the per-user
  PATH (registry-safe REG_EXPAND_SZ, idempotent, with a WM_SETTINGCHANGE
  broadcast), so the documented CLI actually works from any terminal instead of only
  via the full path. ods uninstall removes the entry again.
• Dependency preflight. install.ps1 checks for rclone + git and offers to
  install a missing one via winget — prompting first, -YesDeps to auto-approve
  (non-interactive), -SkipDeps to skip the check entirely. No more first-sync
  failing silently because rclone isn't there.
• Checksum-verified downloads. install.ps1 -FromRelease verifies each binary
  against its published .sha256 before running it (a mismatch aborts; an absent
  sidecar, as on older releases, warns and skips).
• ods update: re-runs the online installer in a detached console to pull the
  latest release and swap the binaries in place (a running exe can't overwrite itself).

Fixed

• ods uninstall now fully removes %LOCALAPPDATA%\ods. The self-delete helper
  (which must outlive the exiting ods.exe to delete its own directory) never actually
  worked: its command line was mangled by argument quoting, so rmdir got a broken path
  and left the whole dir — its ~10 MB of binaries — behind after a "successful" uninstall.
  It now spawns a detached cmd retry loop with a raw command line (retries past a
  lingering ods-gui.exe tray lock, ~40 s cap, and breaks away from the launcher's job).
• Corrected the stale "installer bundles rclone here" comments in paths.rs /
  engine.rs / CLAUDE.md: the local rclone.exe is an optional override only; the
  normal path is rclone on PATH.
• install.ps1 / get.ps1 are now pure ASCII — removes the latent
  powershell.exe -File mis-parse from em-dashes in a no-BOM script.

Full Changelog: v0.2.0...v0.3.0

ods v0.2.0

Full Changelog: v0.1.0...v0.2.0

ods v0.1.0

Full Changelog: https://github.com/AlonRR/onedrive-sync/commits/v0.1.0