Skip to content

fix(collective): skip unsupported Windows directory fsync - #168

Closed
zts212653 wants to merge 1 commit into
mainfrom
fix/f290-windows-directory-sync
Closed

zts212653 wants to merge 1 commit into
mainfrom
fix/f290-windows-directory-sync

Conversation

@zts212653

Copy link
Copy Markdown
Owner

What

  • Centralize directory-entry durability in one syncDirectory helper.
  • Skip only directory-handle fsync on win32, where Node returns EPERM.
  • Route all six Collective persistence paths through that helper: bootstrap credentials, Service state, GitHub App setup, Connector state, attachment custody, and context-reference keys.
  • Add a regression that reproduces the Windows EPERM after the bootstrap file itself was durably written, plus a counterexample proving non-Windows I/O errors still propagate.

Why

The real Windows desktop consumer failed first activation of official.collective-connector at dist/business/service/bootstrap-files.js:69, the directory handle's sync() call. The file write and file-handle sync() had already completed. Catching EPERM broadly would hide real permission or storage failures, so the fix uses the explicit platform contract instead.

Test evidence

  • Regression before implementation: Windows case failed with injected EPERM; non-Windows EIO case already propagated.
  • pnpm --dir packages/collective-connector build — pass.
  • pnpm --dir packages/collective-connector typecheck — pass.
  • pnpm --dir packages/collective-connector test — pass: lifecycle 13, control 62, transport 3, business 438.
  • pnpm --dir packages/collective-connector test:installed — pass: packaged lifecycle/CLI 5.
  • pnpm --dir packages/collective-connector test:source — pass: source/package continuity 4.
  • git diff --check — pass.

Boundaries

  • File-handle sync(), atomic rename/link behavior, privacy checks, and non-Windows directory-sync failures remain enforced.
  • This PR does not change a package version, candidate/live catalog, npm publication, installation, or runtime data.
  • A real Windows positive needs a subsequently published package containing this commit; that distribution acceptance is separate from source review.
  • Draft PR fix(collective): recover expired first-owner setup from the owner launcher #153 overlaps bootstrap-files.ts and Service persistence and will need to rebase onto the landed helper; this PR does not change its owner-bootstrap recovery behavior.

[小太阳·砚砚/gpt-5.6-sol🐾]

Why: The real Windows desktop consumer reached a fully written owner bootstrap file, then failed plugin activation because Node rejects fsync on directory handles with EPERM. Centralize directory durability so Windows skips only that unsupported metadata flush while every file fsync, rename, permission check, and non-Windows I/O error remains enforced.

[小太阳·砚砚/gpt-5.6-sol🐾]
@zts212653

Copy link
Copy Markdown
Owner Author

Superseded by #167, which landed as d051c45. Its approved exact tree contains the original Windows durability commit 7a4f778 with all eight reviewed source files byte-identical. Exact-head CI 40951084156 passed, and @clowder-ai/collective-connector@0.1.0-alpha.22 is now published with the candidate SHA1 e5bd4cd216a4416658d432b90c0cbcf46b12730a and matching SRI. Closing this source-only PR avoids a duplicate delivery path; native Windows first-activation acceptance remains a separate downstream check and is not claimed here.

[小太阳·砚砚/gpt-5.6-sol🐾]

@zts212653 zts212653 closed this Oct 29, 2026
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