Skip to content

A disk mounted as a folder gets its free space counted on its own (#1041) - #1104

Merged
ccoventry merged 3 commits into
devfrom
fix/mounted-folder-volume-1041
Oct 29, 2026
Merged

ccoventry merged 3 commits into
devfrom
fix/mounted-folder-volume-1041

Conversation

@ccoventry

Copy link
Copy Markdown
Owner

Release note: Fixed: a disk mounted as a folder inside another drive now has its free space counted on its own, so capture and render don't treat it as the drive around it.

Closes #1041

What changes

  • sys::disk::volume_key keys a drive-letter path by its Windows volume name (\\?\volume{guid}\): GetVolumePathNameW finds the mount point the path is under (its nearest existing folder decides, so a folder not made yet still keys by the volume it'll be on), then GetVolumeNameForVolumeMountPointW names that volume. So D:\Captures mounted from a second disk keys apart from D:. Two folders on one plain drive still share one key.
  • Falls back to the old key (c:, \\server\share) when Windows has no volume name: a network share (deliberately not asked, since an offline share would wait on the network), a subst drive, or a drive letter that isn't there.
  • Every place that grouped by drive now goes through it: build_batch_queue's per-drive budgets (group_by_volume), the render reservations (ledger_key), the Capture footer's pool total (export_pool_space), and the take cleanup's volume_of (Delete finished takes automatically: Recycle Bin or permanent, optionally only when space is needed (part of #644) #716), which had its own copy of the prefix rule.
  • Free space itself already used the longest mount point a path is under (get_available_bytes), so it was right for a mounted folder; only the grouping was wrong.
  • Not changed: the frontend's same-drive warning (refreshSameDriveWarning) still compares drive letters.

Test done

  • New test a_drive_keys_by_its_volume_name: the system drive keys as \\?\volume{…}, a folder that doesn't exist on it keys the same, a missing drive letter keys as the letter. Updated the two tests that compared against the literal c:/d:.
  • cargo test -p native -p desktop-studio pass; clippy 1.98.1 + fmt clean.
  • Not tested with a real folder mount. This PC has none, and making one (mountvol/Disk Management) needs admin.

🤖 Generated with Claude Code

volume_key names a drive-letter path's volume (GetVolumePathNameW +
GetVolumeNameForVolumeMountPointW), falling back to the drive or share
prefix; take_cleanup's volume_of goes through it too.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ccoventry

Copy link
Copy Markdown
Owner Author

Results of the overnight check (unattended pass, 2026-10-29)

Merged origin/dev in (b4d1607e): no conflicts.

Tests

  • cargo test --workspace --locked --exclude goldsrc-hooks --exclude web-analyzer: the first full run had 2 failures in the native lib (912 pass) while I was also running vitest and a cargo build; they were not named in my filtered output, and a clean re-run of cargo test -p native --lib --locked passes (914, 12 ignored), including sys::disk::tests::a_drive_keys_by_its_volume_name. I take it for load flakiness but did not identify the two tests, so flagging it. CI's Rust workspace tests pass on this head.
  • npm run test:unit: 1019 pass. Playwright e2e whole suite (CI=1): 433 pass, including app-boot.spec.js.
  • CI on the merged head: Clippy, Rust workspace tests, Frontend e2e, Hooks 32-bit, Web analyzer all pass.

Live test with a real folder mount (debug build of this branch in a real Tauri window, own settings folder): the test volume is a VHD mounted at C:\mnt\test1104 with no drive letter (NTFS, 2,111,942,656 bytes free).

  • Capture Destinations = C:\mnt\test1104\takes (I created the folder): the Capture footer says Capture Output Free: 2.0 GB, the VHD's own space, not C:'s (about 442 GiB).
  • calculate_export_pool_space invoked in the live app: [VHD takes] = 2,111,938,560; [C: folder] = 474,324,717,568; [VHD, C:] and [C:, VHD] both = 476,436,656,128 (the sum of the two volumes, either order); two folders on C: = C: once (474,324,717,568); the VHD's takes plus its root C:\mnt\test1104 = the VHD once (2,111,938,560). The Render footer, with the VHD folder and a C: folder as export dirs, said "Export Pool Free: 445.1 GB" (about 442 + 2).
  • Not run: the same checks on the old code (dev) to show the "before" number; by the PR's description it keyed both as c: and counted one of them. Not exercised live: the batch budget path (group_by_volume) and the render reservations, which are covered by the unit tests only.
  • Screenshot: local\review-images\1104\capture-footer-vhd.png (a "Render Batch Interrupted" dialog from an earlier stop of my test Studio sits on top of it; unrelated).

Verdict: ready to merge.

@ccoventry
ccoventry merged commit abeff71 into dev Oct 29, 2026
5 checks passed
@ccoventry
ccoventry deleted the fix/mounted-folder-volume-1041 branch October 29, 2026 07:11
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.

A drive mounted as a folder counts its free space under two names

1 participant