Skip to content

fix: capture volumes under concurrent mounts - #96

Merged
sasan1200 merged 1 commit into
mainfrom
fix/capture-mount
Oct 22, 2026
Merged

sasan1200 merged 1 commit into
mainfrom
fix/capture-mount

Conversation

@sasan1200

Copy link
Copy Markdown
Member

Changes

  • Capture volume mount checks read the hdiutil image listing again, waiting at most 1.55 s, when it is inconsistent or missing an image that was just attached. A listing that stays inconsistent is still refused.
  • The capture removal preview identifies files by path, inode, size and content. It no longer includes the volume's device number, which changes when the image is attached again after another disk image took that number.

Verification

  • Two capture test processes at once on main: a failure in each of 3 rounds ("did not mount at its owned path" or "has an unexpected mount"), with mounted images left behind. Traces show the listing missing the image about 20 ms after a successful attach, while the next read lists it.
  • With this change: 5 rounds of two processes, with no failures and no images left attached.
  • A file's device number moves from 16777243 to 16777244 when its image is attached again after another image; its inode stays 18.
  • New tests fail against main's modules and pass here: a lagging or half-listed listing, a persistently inconsistent listing still refused, and removal after the capture remounts on another device.
  • compileall, release version, contracts, JSON schemas, generate_adapters --check, render_compatibility --check, the unit suite and git diff --check pass.

@sasan1200
sasan1200 merged commit b07f4e0 into main Oct 22, 2026
8 checks passed
@sasan1200
sasan1200 deleted the fix/capture-mount branch October 22, 2026 02:17
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