[sidick]

Summary

Tier 2 of the dos.library LVO gap scan (#159; PR #161 did Tier 1). Both calls needed a small refactor first, which is why they weren't folded into #161 directly.

• OpenFromLock: DosState::open's "resolve a name through the Vfs" step and its "open a host path per access_mode and register a guest FileHandle" step are now split (the latter is open_resolved), so OpenFromLock can skip straight to the second step using a lock's already-resolved (host_path, amiga_path) from doslock::LockEntry instead of re-resolving a name. Per the real autodoc ("the lock is (effectively) relinquished, and should not be UnLock()ed or used [again]... If the open fails, the lock is still usable"): a successful open calls the existing unlock() on the lock itself (same cleanup a real UnLock() does), and a failed open leaves the lock entirely untouched.

  Judgment call: the autodoc says the resulting handle's access mode "is of the same access mode as the lock you gave up -- shared is similar to MODE_OLDFILE, exclusive is similar to MODE_NEWFILE." Taken literally that would mean create-and-truncate for an exclusive lock -- but the file necessarily already exists (that's how the lock came to exist at all), so MODE_NEWFILE's truncating semantics would destroy data for no real reason. This implementation always opens the existing file read+write (falling back read-only), the same as open()'s MODE_OLDFILE branch, for both lock access modes -- reading "NEWFILE-like" as describing the resulting handle's nominal label (which this runtime doesn't track per-handle at all), not a license to re-create an already-locked file.

• ChangeMode: this runtime models no real concurrency (single process, same posture as the existing InitSemaphore/ObtainSemaphore family and AddTask's unscheduled-task stub), so there's nothing for a mode change to actually enforce -- same as there's no real shared/exclusive enforcement for Lock to begin with. Validates that the referenced lock (CHANGE_LOCK) or filehandle (CHANGE_FH) exists and reports success; the real autodoc's own "the handler may well reject this request" already tells callers not to rely on this unconditionally anyway.

  Judgment call: on the lock side, newmode is written into LockEntry::access, mirroring that field's existing "recorded for debuggability only" convention. On the filehandle side there's no equivalent field on HostHandle::HostFile -- adding one purely to record a value nothing else in this runtime ever reads back would be exactly the kind of defensive bookkeeping the semaphore/task stubs already decline to do, so reporting success without persisting anything is the honest-enough answer there.

Test plan

• Unit tests for DosState::open_from_lock (success + lock relinquished, unknown lock -> ERROR_INVALID_LOCK, failed open leaves the lock usable) and DosState::change_mode (lock success + recorded access, unknown lock, filehandle success, unknown filehandle, invalid type).
• Real end-to-end tests driving actual A-line trap dispatch for both calls (Lock -> OpenFromLock -> Read round-trip; OpenFromLock on an unknown lock; Lock -> ChangeMode(CHANGE_LOCK); ChangeMode on an unknown lock) -- proves the real LVO offsets (-378/-450) and register assignments, not just the underlying logic.
• cargo test --workspace (1080 tests, up from 1068) passes; cargo clippy --workspace --all-targets and cargo fmt --check clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Godbk9UDW5obqYsdkXkyRR