Skip to content

fix: stop repeated .univer backups on Windows - #57

Merged
OTime-Coder merged 2 commits into
mainfrom
fix/windows-univerfile-upgrade-backups
Sep 24, 2026
Merged

OTime-Coder merged 2 commits into
mainfrom
fix/windows-univerfile-upgrade-backups

Conversation

@OTime-Coder

Copy link
Copy Markdown
Member

Summary

  • On Windows, libsql keeps a .univer file locked after close(), so the in-process upgrade rename fails and the original stays on the old format.
  • Migration now runs in dist/upgrade-worker.js. The parent replaces the original only after that process exits.
  • If the upgrade still fails, a later open of the same unchanged file reuses the existing same-byte backup instead of copying another one. A file whose bytes changed still gets its own backup.

Test plan

  • pnpm --filter @univer/univerfile-sqlite test
  • pnpm --filter @univer/univerfile-sqlite typecheck
  • node apps/cli/scripts/build.mjs emits dist/upgrade-worker.js, and node apps/cli/dist/bin.js --help still starts the CLI
  • On Windows, open one old .univer file and confirm only one *.backup-* appears and the file opens

Made with Cursor

OTime-Coder and others added 2 commits September 25, 2026 01:28
libsql keeps the database locked after close on Windows, so an
in-process rename fails and the next open leaves another backup.
Migrate in a helper process, then replace the original after it exits,
and reuse a same-byte backup when that open is retried.

Co-authored-by: Cursor <cursoragent@cursor.com>
The bundled helper and its subprocess migrations exceed Vitest's
default 5s limit on the Linux runner.

Co-authored-by: Cursor <cursoragent@cursor.com>
@OTime-Coder
OTime-Coder merged commit 7ec4b8d into main Sep 24, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant