Repository navigation
Add macOS support to the GUI - #1010
Merged
Merged
Conversation
MPF found no drives at all on macOS. Environment.OSVersion.Platform reports PlatformID.Unix there, so GetDriveList took the Linux path, whose enumerators read /sys/block, /sys/class/scsi_generic and /dev/sr*. None of those exist on macOS, so each returned nothing without failing and the drive list came back empty, leaving the GUI showing "Found no drives". macOS now has its own enumerator built on `diskutil info`, mirroring the structure of Drive.Linux.cs. Optical drives are identified by the presence of diskutil's optical-only fields rather than by any value they carry: an emulated drive leaves "Optical Media Type" blank and reports its protocol as SATA, while a real USB drive fills the field in and reports USB, so neither value is a reliable marker on its own. Optical media is also left out of the DriveInfo query on macOS. macOS mounts every readable disc on insertion, and DriveInfo reports the mounted volume (e.g. "/Volumes/LABEL") as a CD-ROM drive. That is a mount point rather than a dumpable device, and diskutil already surfaces the drive holding the disc as a device node, so it would otherwise show up as a second, unusable entry for every disc that is inserted. Verified on macOS 26 against fixed disks, a USB floppy drive, and both an emulated and a real USB optical drive. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The drive name reaches the dumping program verbatim, and on macOS a program takes a drive as its BSD name rather than as a device node path. Redumper resolves the name against the BSD name IOKit publishes for the drive and fails with "failed to find matching SCSI authoring device" when it is given "/dev/disk4", so every dump from an enumerated drive failed. This mirrors the existing platforms: the name is a drive letter on Windows and a device node on Linux, in both cases the form the program expects. Verified against a USB PLEXTOR PX-760A on macOS 26: redumper reads the drive and dumps a mixed-mode CD when given "disk4". Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
PrepareMacRedumperParameters stripped "--drive" from the Redumper parameters whenever the selected drive name began with "/Volumes/". That was a workaround for enumeration: the only optical entry macOS surfaced was the mounted volume rather than a device, and no dumping program takes a mount point as a drive. Dropping the argument made Redumper fall back to picking the first drive that holds a disc, which is only ever right when a single drive is loaded. With two loaded drives it silently dumped one the user had not selected. Enumeration now surfaces the device itself and passes it as its BSD name, so the workaround has nothing left to match and the guess is no longer needed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A dumping tool gets no console window of its own on macOS, the same as on Linux, so the GUI ran the tool with no visible output at all. The console window added for the Linux GUI (SabreTools#998) already fits: the window, its terminal buffer, and the output pump are platform-neutral. Only the gate that creates the console was limited to Linux, so macOS is added to it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
mnadareski
reviewed
Jul 12, 2026
mnadareski
left a comment
mnadareski
left a comment
Member
There was a problem hiding this comment.
There are definitely going to be merge conflicts given the amount of changes I did.
Two conflicts with the changes queued up upstream: - Drive.Name became Drive.DevicePath, and the helpers the macOS enumerator borrowed from the Linux one (the whole-disk node filter and the floppy media sizes) moved to SabreTools.IO as internals. Both are reproduced here, adjusted for the macOS naming convention (diskN, not srN/sdN). - PrepareMacRedumperParameters() is still removed. It strips "--drive" from the Redumper parameters when the drive name starts with "/Volumes/", which only happens because DriveInfo surfaces a mounted disc as a drive. This branch enumerates the device behind the disc instead, so the drive is named by its BSD name and the strip never applies.
- Drop MacOSBlockDevice and use Drive throughout, the way EnumerateUnixFixedDevices does since UnixBlockDevice was removed. ParseMacOSDiskutilInfo now returns a Drive and EnumerateMacOSDevices a List<Drive>, so the enumerator no longer carries a second type that holds the same fields. The BSD name becomes DevicePath, which is what a macOS dumping program takes and what DumpEnvironment passes on verbatim. - Read the device nodes for the node-filter test from a checked-in TestData directory instead of writing and deleting the same seven files on every run. - Leave the DriveInfo query in GetDriveList as it was. macOS still reports a mounted disc as a CD-ROM drive, so the mount point is dropped in the macOS enumerator, next to the code that surfaces the device behind it. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
mnadareski
approved these changes
Jul 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MPF finds no drives at all on macOS: the GUI shows "Found no drives" and no dump can be started.
Environment.OSVersion.PlatformreportsPlatformID.Unixon macOS, soGetDriveListtakes the Linux path, whose enumerators read/sys/block,/sys/class/scsi_genericand/dev/sr*. None of those exist on macOS, so each returns nothing without failing and the drive list comes back empty.Four commits, each one thing.
Add macOS drive enumeration
A macOS enumerator built on
diskutil info, mirroring the structure ofDrive.Linux.cs.Optical drives are identified by the presence of diskutil's optical-only fields rather than by any value they carry: an emulated drive leaves "Optical Media Type" blank and reports its protocol as SATA, while a real USB drive fills the field in and reports USB, so neither value is a reliable marker on its own.
Optical media is left out of the
DriveInfoquery here. macOS mounts every readable disc on insertion, andDriveInforeports the mounted volume (for example/Volumes/LABEL) as a CD-ROM drive. A mount point is not a dumpable device, and diskutil already surfaces the drive holding the disc, so the volume would only add a second, unusable entry for the same disc.Name macOS drives by BSD name
The drive name reaches the dumping program verbatim. On macOS a program takes a drive as its BSD name rather than as a device node path: redumper resolves the name against the BSD name IOKit publishes for the drive and fails with
when it is given
/dev/disk4. Without this, every dump from an enumerated drive fails.This mirrors the existing platforms: the name is a drive letter on Windows and a device node on Linux, in both cases the form the program expects.
Remove the Redumper drive workaround on macOS
PrepareMacRedumperParametersstripped--drivefrom the Redumper parameters whenever the selected drive name began with/Volumes/. It existed because the mounted volume was the only optical entry macOS used to surface, and no dumping program takes a mount point as a drive.Dropping the argument made Redumper fall back to picking the first drive that holds a disc, which is only ever right when a single drive is loaded. With two loaded drives it silently dumped one the user had not selected.
With the device itself enumerated and passed as its BSD name, the workaround has nothing left to match and the guess is no longer needed.
Show the tool output console on macOS
A dumping tool gets no console window of its own on macOS, the same as on Linux, so the GUI ran the tool with no visible output at all.
The console window added for the Linux GUI (#998) already fits: the window, its terminal buffer, and the output pump are platform-neutral. Only the gate that creates the console was limited to Linux, so macOS is added to it. This is the whole change:
Verification
macOS 26 (x86_64) with a USB PLEXTOR PX-760A. The drive is enumerated, selected in the GUI, and dumped end to end with redumper: a mixed-mode CD, 0 SCSI errors, 0 C2 errors, and a
.scrambyte-for-byte identical in size to the same disc dumped on Linux. The tool output console shows the live output during the dump.316 lines of tests are added to
MPF.Frontend.Test/DriveTests.cs, covering the diskutil parsing, the optical-drive detection, and the BSD naming. The suite is green (582 tests).Prepared with AI assistance (Claude Opus 4.8) and reviewed before submission.