Fixes
Truncating a file to zero bytes now works over every serve backend (#37)
A zero-byte file has no network object behind it, so every backend passed an empty fileId to the replace endpoint — which answers that with a 500. Truncating an existing Drive file to zero had therefore never worked on any protocol. WebDAV surfaced the error; SMB, SFTP, NFS and FUSE flush after close, so the client saw a successful write while the file silently kept its old content.
The empty case now falls back to trash-then-create (with the original restored from the trash if the create fails), and NFS adopts the resulting uuid so a later write doesn't target a trashed entry. Verified live over WebDAV, SMB, SFTP, FUSE and NFS.
Anyone mounting Drive from a client that writes zero-byte sidecar files — QNAP CacheMount and similar — was hitting this on every retry.
ixr update no longer installs a different version than it reported (#36)
self_update re-derived "latest" through a semver-caret filter, which treats a 0.x minor bump as breaking, so a 0.2.0 -> 0.3.0 prompt could actually install 0.2.1. The resolved version is now pinned explicitly, so --check and the install always agree.
Adds --patch-only (opt back into same-minor updates) and --version <VER> (install an exact version, downgrades included). --check now prints the exact ixr update invocation that reproduces the target it reported.
Internals
Engine dependency moved to internxt-core 0.1.8, which carries the replace/recreate fallback and its trash rollback.
What's Changed
- fix(update): stop check/install disagreeing on target version by @Bebbssos in #36
- fix(serve): stop losing writes that truncate a file to zero bytes by @Bebbssos in #37
Full Changelog: v0.3.0...v0.3.1
