#39 Feature: FileVault no-mount unlock and read-only mounting

[cf-eglendye]

Fix #39 Feature: FileVault no-mount unlock and read-only mounting.

NOTE: The updates made in this commit were implemented by Claude Code. All prompts written and code functionality for unlocking FileVault-encrypted volumes tested by Elliot Glendye on a MacBook Pro M2 macOS 26.

---

Three runtime bugs and one build-time bug corrected after initial deployment of the FileVault unlock feature in macOS Recovery.

• Allow locked volumes to be focused in the device list on_item_focused previously bounced focus away from any row without a mount point. Locked FileVault volumes have no mount point, so they could not be clicked or highlighted. Added elif device.is_locked branch to permit focus without mounting anything.

• Trigger unlock dialog on double-click of a locked volume on_item_activated had the same gatekeeper. Added elif device.is_locked branch that calls _run_unlock_dialog(preferred_identifier=...) so double-clicking a locked row opens the dialog pre-aimed at that volume.

• Fix AttributeError crash before password dialog appeared FileVaultUnlockDialog expects List[EncryptedVolume] but the unlock handler was passing List[DeviceInfo]. The first attribute access (v.roles) crashed before the dialog rendered. Refactored the unlock logic into _run_unlock_dialog(), which now calls list_encrypted_volumes() directly to obtain correctly typed objects. on_unlock_filevault() is now a one-line delegate to _run_unlock_dialog().

No forensic behaviour is altered. All changes affect either the tool's own UI interaction model or its build artefacts. No source disk writes are introduced.

[Lazza]

Thank you for suggesting this PR! I am now starting to review the code and I will make some adjustments. Specifically, I think some parts of the code could re-use existing functionality in other parts of Fuji, such as checking if a directory is a mount pont (but I will check in more detail).

Regarding this part:

Ensure launcher script has execute bit after build and RAM disk copy shutil.copy() inherits permissions from the source file. When built from a Windows/NTFS filesystem, Fuji.sh has no execute bit, producing a non-executable launcher and "The application can't be opened" in Recovery. Added explicit chmod(0o755) in Fuji.spec after the copy. Added a matching chmod in attempt_ramdisk() after the ditto copy as defence in depth.

Is it necessary? I don't see this issue and, indeed, the proposed PR does not do any chmod operation. Maybe it can be removed from the PR description.

For this part, were the errors encountered for real or was the function merely written by Claude?

https://github.com/Lazza/Fuji/pull/40/changes#diff-a46b150edb68d2361cc92a2da7ee9ea7c4cc77585ad7be12b364e2ef1df3d872R209-R224

I am asking because some of the error messages seem a bit unusual.

---

Generally speaking I quite like this feature suggestion and I am happy to review it, but I will try to trim down the code a little bit, in order to stick to the KISS principle. 🙂

[cf-eglendye]

Thank you for taking the time to review the code.

More than happy for you to make amends / streamline where necessary.

The particular error you are referring to happened was a genuine error I experienced, when I was building on Windows; during testing I used Mac (no issues) and Windows (had issues).

I would recommend removing these references and continue to make recommendation to build on macOS.