fix: accurate disk space check on Linux #27

korbo · 2026-11-13T10:43:51Z

korbo commented

2026-11-13 10:43:51 +00:00

First-time contributor

what this fixes: on linux, check the directory directly for its disk space

I couldn't build on bazzite linux because the existing code calculated me as having 0 GB free space with the composefs on /

how i tested it: built it myself and ran it, and now i can use the Build button in the launcher.

what this fixes: on linux, check the directory directly for its disk space I couldn't build on bazzite linux because the existing code calculated me as having 0 GB free space with the `composefs` on / how i tested it: built it myself and ran it, and now i can use the Build button in the launcher.

korbo added 1 commit

2026-11-13 10:43:51 +00:00

fix: accurate disk space check on Linux

CI / Conventional Commit title (pull_request) Has been cancelled

Details

CI / Compile and test (pull_request) Has been cancelled

Details

8837f9a13b

HumanBean requested changes

2026-11-13 10:57:49 +00:00

HumanBean left a comment

Thanks, this fixes the real problem: on Bazzite /home is a link to /var/home, GetFullPath keeps the link, so the old mount matching picked the composefs root with 0 bytes free. Asking statvfs about the folder itself (which new DriveInfo(dir) does on Unix) follows the link to the right filesystem.

One thing to fix before merge: Disk.DriveName still matches mounts by the unresolved path, so it now disagrees with FreeBytes. On Bazzite the settings step will say "200 GB free on /", and when the real filesystem is short, "/ is too full for the build", which points the player at the wrong drive. Details inline.

Also, please add to the description how you tested it (CONTRIBUTING asks for why, what changed and how it was tested): did you run tests/test_launcher_core.py, and did the launcher on Bazzite show the right free space afterwards?

Thanks, this fixes the real problem: on Bazzite `/home` is a link to `/var/home`, `GetFullPath` keeps the link, so the old mount matching picked the composefs root with 0 bytes free. Asking statvfs about the folder itself (which `new DriveInfo(dir)` does on Unix) follows the link to the right filesystem. One thing to fix before merge: `Disk.DriveName` still matches mounts by the unresolved path, so it now disagrees with `FreeBytes`. On Bazzite the settings step will say "200 GB free on /", and when the real filesystem is short, "/ is too full for the build", which points the player at the wrong drive. Details inline. Also, please add to the description how you tested it (CONTRIBUTING asks for why, what changed and how it was tested): did you run `tests/test_launcher_core.py`, and did the launcher on Bazzite show the right free space afterwards?

Core/Disk.cs

					
				@ -67,1 +67,4 @@

				            }

				            // Unix accepts a directory here and asks the filesystem holding it for space.

				            // Let the OS follow links and mounts.

				            if (!OperatingSystem.IsWindows()) return new DriveInfo(at).AvailableFreeSpace;

This gives the right number, but DriveName (below, not in the diff) still picks the longest mount root that the unresolved path starts with. For /home/you/... on Bazzite it returns /, while this now measures /var. SettingsStepViewModel pairs the two (MeterText: "{f} GB free on {Drive}", SpaceWarning: "{Drive} is too full for the build"), so the window names the wrong mount.

Could both use the same resolved location? For example a small helper that resolves links along the path (walk the components, ResolveLinkTarget(returnFinalTarget: true) where LinkTarget != null), used by DriveName on Unix; then this line can stay as is, or FreeBytes could keep its mount matching on the resolved path so the two can't drift apart again. A check next to yours that DriveName(linkedMount) == "/proc" would hold it.

This gives the right number, but `DriveName` (below, not in the diff) still picks the longest mount root that the *unresolved* path starts with. For `/home/you/...` on Bazzite it returns `/`, while this now measures `/var`. `SettingsStepViewModel` pairs the two (`MeterText`: "{f} GB free on {Drive}", `SpaceWarning`: "{Drive} is too full for the build"), so the window names the wrong mount. Could both use the same resolved location? For example a small helper that resolves links along the path (walk the components, `ResolveLinkTarget(returnFinalTarget: true)` where `LinkTarget != null`), used by `DriveName` on Unix; then this line can stay as is, or `FreeBytes` could keep its mount matching on the resolved path so the two can't drift apart again. A check next to yours that `DriveName(linkedMount) == "/proc"` would hold it.

ok I can fix DriveName too

yeah I was just wondering if either OS will accept return new DriveInfo(at).AvailableFreeSpace tbh

ok I can fix DriveName too yeah I was just wondering if either OS will accept `return new DriveInfo(at).AvailableFreeSpace` tbh

korbo marked this conversation as resolved

tests/launcher_core/ScreenChecks.cs

					
				@ -422,0 +423,4 @@

				        {

				            // Follow links for disk space accuracy.

				            var linkedMount = Path.Combine(root, "other-mount");

				            Directory.CreateSymbolicLink(linkedMount, "/proc");

Nit: say why /proc: its statvfs reports 0 free, so the check fails if the link isn't followed (the old code would report the free space where root is). Comparing with new DriveInfo("/proc").AvailableFreeSpace restates the implementation; == 0 with that comment reads more plainly.

Nit: say why `/proc`: its statvfs reports 0 free, so the check fails if the link isn't followed (the old code would report the free space where `root` is). Comparing with `new DriveInfo("/proc").AvailableFreeSpace` restates the implementation; `== 0` with that comment reads more plainly.

👍 1

korbo marked this conversation as resolved

HumanBean referenced this pull request

2026-11-13 11:00:55 +00:00

fix: accurate disk space and drive name on Linux, through links #29

HumanBean commented

2026-11-13 11:00:56 +00:00

Thanks for the fix, korbo! This PR doesn't allow maintainers to push to its branch, so it's carried on in #29. That PR keeps your commit as it is and adds the DriveName fix from the review on top. Closing this one in favour of it.

Thanks for the fix, korbo! This PR doesn't allow maintainers to push to its branch, so it's carried on in https://git.magicbean.dev/MagicBeanDev/LongshotLauncher/pulls/29. That PR keeps your commit as it is and adds the `DriveName` fix from the review on top. Closing this one in favour of it.

HumanBean closed this pull request

2026-11-13 11:00:56 +00:00

HumanBean referenced this pull request from a commit

2026-11-13 11:01:28 +00:00

fix: accurate disk space and drive name on Linux, through links (#29)

CI / Conventional Commit title (pull_request) Has been cancelled

Details

CI / Compile and test (pull_request) Has been cancelled

Details

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

No reviewers

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

MagicBeanDev/LongshotLauncher!27

Rows
Columns