Fall back from protected installation-adjacent workspaces to user-writable storage

[bobtista]

Problem

The packaged Alpha 4 candidate cannot launch a profile from a normal non-administrator Windows session when the detected game is installed under a protected location such as Program Files.

StorageLocationService prefers installation-adjacent workspaces. Workspace preparation then fails before the game process starts when the packaged application cannot create or modify that directory.

Moving the workspace into user-writable storage also exposes two related problems:

• HardLinkStrategy rejects cross-volume workspace preparation before reaching its existing copy fallback.
• Existing workspace metadata can reuse a workspace under the previous protected root after storage resolution changes.
• Profile editing and launching must resolve the same workspace root to avoid unnecessary recreation.

This blocks the “A profile can be created and launched” Windows validation item in #307.

Expected behavior

GenHub should create and launch profiles without administrator privileges when the game is installed under Program Files.

Writable installation-adjacent workspaces should remain available for same-volume hard-link efficiency. When that location is unavailable, GenHub should use a writable configured workspace or the application-data workspace directory and copy files when hard links cannot cross volumes.

Scope

This issue covers workspace selection, workspace reuse, and cross-volume workspace preparation.

The installation CAS pool has a separate protected-path problem: acquisition code persists <installation>/.genhub-cas, and the CAS resolver treats a nonempty path as available without checking writability. That requires separate handling for pool resolution, persisted settings, and existing CAS content.

Acceptance criteria

• A packaged Windows build running without administrator privileges falls back from a protected installation-adjacent workspace to user-writable storage.
• Writable installation-adjacent workspaces continue to work.
• A writable configured workspace path is honored.
• Profile editing and launching use the same workspace resolver.
• Hard-link workspaces copy content instead of failing when workspace storage is on another volume.
• A workspace stored under the previous root is recreated under the currently resolved root.
• Filesystem path comparisons respect platform case sensitivity.
• Focused regression tests and the complete Core test suite pass.
• The packaged Alpha 4 candidate can create and launch a profile from a protected Windows installation.

Implementation

Addressed by #346.

Packaged non-administrator Windows validation and CI results are still required before the issue is complete.

Related work

• Alpha 4 readiness: Release: Alpha 4 readiness checklist #307
• Installation-adjacent storage: feat(storage): implement dynamic storage location service with user notifications #210
• Workspace fallback implementation: fix(workspace): fall back from protected adjacent storage #346
• Protected installation CAS pool: tracked separately

[coderabbitai]

🔗 Related PRs

#288 - feat: Add GenLauncher file normalization support [open]
#328 - feat(platform): make paths, manifests, and Unix workspaces platform-aware [merged]
#329 - feat(macos): add native host, installation detection, and CI [merged]
#332 - feat(launching): launch the native BGFX client against retail archives [open]
#345 - fix(tests): pass the absolute path to the executable classifier [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Add a writability probe and precedence-based fallback to StorageLocationService so workspace and CAS paths always resolve to a user-writable location, with configured user paths taking precedence.
• Honor configured writable CAS paths and fall back to application-data storage in ConfigurationProviderService.GetCasConfiguration().
• Remove the early cross-volume abort in HardLinkStrategy and centralize hard-link-with-copy fallback in IFileOperationsService/WindowsFileOperationsService.
• Detect a changed storage root in WorkspaceManager and recreate the workspace, then add focused regression tests for each behavior.

Design Choices

Design Choice 1: Location of the writability probe and fallback selection

Options Considered:

1. Add the probe to StorageLocationService.GetWorkspacePath/GetCasPoolPath and return the first writable path.
2. Keep resolution unchanged and add retry-with-fallback logic inside WorkspaceManager when ValidateConfigurationAsync reports a write failure.

Chosen Option: 1

Rationale: StorageLocationService is the single source of path selection. Probing there keeps every caller (ProfileLauncherFacade, GameLauncher) consistent. It avoids threading fallback state through WorkspaceManager.

Design Choice 2: Method for the workspace stale-root comparison without a persisted root field

Options Considered:

1. Compare the persisted WorkspaceInfo.WorkspacePath against Path.Combine(configuration.WorkspaceRootPath, configuration.Id) with normalized string comparison.
2. Add a new WorkspaceRootPath property to WorkspaceInfo, populate it in WorkspaceStrategyBase.CreateBaseWorkspaceInfo, and compare the stored value to the current config.

Chosen Option: 1

Rationale: The string comparison is lower risk. It needs no schema or serialization change to workspaces.json. It reuses values already present.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Writable storage resolution with fallback

This phase makes StorageLocationService select only writable storage locations. It adds an actual filesystem writability probe. It honors explicitly configured user paths first. It keeps installation-adjacent storage when it is writable. It falls back to user-writable application-data storage when the adjacent location is protected. This directly resolves the Program Files launch failure.

Task 1: Add a reusable writability probe

Introduce one probe that tests whether a directory is user-writable.

• Add a private probe method inside GenHub/GenHub/Common/Services/StorageLocationService.cs that mirrors the existing WorkspaceValidator pattern: attempt Directory.CreateDirectory, write a temporary file, delete it, and return true on success.
• The probe must catch UnauthorizedAccessException, IOException, and SecurityException, log a warning, and return false.
• The probe must never throw to callers. A false result drives fallback selection.

Task 2: Add fallback selection to workspace and CAS path resolution

Change GetWorkspacePath and GetCasPoolPath to return the first writable location in a defined precedence order.

• Update GetWorkspacePath(IGameInstallation) in StorageLocationService.cs to resolve in this order: (1) a user-configured writable path from IConfigurationProviderService.GetWorkspacePath() when UserSettings.IsExplicitlySet(nameof(UserSettings.WorkspacePath)) is true and the path is writable; (2) the installation-adjacent path when UseInstallationAdjacentStorage is true and that path is writable; (3) the centralized application-data workspace path as the final writable fallback.
• Update GetCasPoolPath(IGameInstallation) with the symmetric order using IConfigurationProviderService.GetCasConfiguration().CasRootPath for the configured path and the centralized %LocalAppData%/GenHub/cas-pool path as the final fallback.
• Inject IConfigurationProviderService into StorageLocationService. Confirm no dependency cycle exists (ConfigurationProviderService does not depend on IStorageLocationService).
• Replace the hardcoded "Workspaces" literal with the appropriate DirectoryNames constant to keep the centralized workspace path consistent with the CAS path handling.
• Log one informational message when the resolver falls back from an installation-adjacent path to centralized storage, so the fallback is observable.

Task 3: Honor configured user CAS path in the CAS pipeline

Ensure the CAS backend uses a writable root when a custom CAS path is configured or when the default is unavailable.

• Update ConfigurationProviderService.GetCasConfiguration() in GenHub/GenHub/Common/Services/ConfigurationProviderService.cs to probe the effective CasRootPath for writability and fall back to the application-data default when the configured or default path is not writable.
• Reuse the same probe behavior defined in Task 1.1. Extract the probe to a small shared helper in GenHub/GenHub/Common/Services/ if it is needed in both services, to avoid duplicated write-test logic.
• Log a warning when the configured CAS path is not writable and the resolver applies the fallback.

🤖 Prompt for AI agents

Implement writable storage resolution with fallback in `StorageLocationService`
and `ConfigurationProviderService`. Goal: workspace and CAS path resolution must
always return a user-writable location, honoring configured paths first.

- In `GenHub/GenHub/Common/Services/StorageLocationService.cs`, add a private
writability probe method that mirrors the `WorkspaceValidator` pattern: call
`Directory.CreateDirectory`, write a temporary file, delete it, and return
`true` on success. Catch `UnauthorizedAccessException`, `IOException`, and
`SecurityException`; on any of these, log a warning and return `false`. The
probe must never throw to callers.
- Update `GetWorkspacePath(IGameInstallation)` to resolve paths in this
precedence order: (1) a user-configured writable path from
`IConfigurationProviderService.GetWorkspacePath()` when
`UserSettings.IsExplicitlySet(nameof(UserSettings.WorkspacePath))` is true and
the probe confirms writability; (2) the installation-adjacent path when
`UseInstallationAdjacentStorage` is true and it is writable; (3) the centralized
application-data workspace path as the final fallback.
- Update `GetCasPoolPath(IGameInstallation)` symmetrically, using
`IConfigurationProviderService.GetCasConfiguration().CasRootPath` for the
configured path and the centralized `%LocalAppData%/GenHub/cas-pool` path as the
final fallback.
- Inject `IConfigurationProviderService` into `StorageLocationService`. Verify
there is no dependency cycle (`ConfigurationProviderService` must not depend on
`IStorageLocationService`).
- Replace the hardcoded `"Workspaces"` literal with the appropriate
`DirectoryNames` constant.
- Log an informational message when the resolver falls back from an
installation-adjacent path to centralized storage.
- Update `ConfigurationProviderService.GetCasConfiguration()` to probe the
effective `CasRootPath` for writability and fall back to the application-data
default when the configured or default path is not writable. Reuse the probe
logic from the writability probe; if needed in both services, extract it into a
small shared helper in `GenHub/GenHub/Common/Services/` to avoid duplication.
Log a warning when the fallback is applied due to a non-writable configured CAS
path.

Phase 2: Cross-volume hard-link copy fallback

This phase lets a hard-link workspace complete when fallback storage is on a different volume than the game installation. It removes the early cross-volume abort in HardLinkStrategy and routes cross-volume files through the existing per-file copy fallback.

Task 1: Remove the cross-volume hard abort in HardLinkStrategy

Change the top-level volume gate so preparation continues instead of failing.

• Update HardLinkStrategy.PrepareAsync in GenHub/GenHub/Features/Workspace/Strategies/HardLinkStrategy.cs to remove the early return that sets IsPrepared = false and adds an Error-severity ValidationIssue on volume mismatch.
• Let the per-file loop run for all cases. The loop must attempt a hard link and copy the file when the hard link fails because of a cross-volume condition.
• Keep same-volume behavior unchanged so same-volume hard-link efficiency remains.

Task 2: Centralize hard-link-with-copy-fallback behavior

Make the cross-volume copy fallback reliable for arbitrary source-to-destination hard links.

• Add an allowFallback parameter to CreateHardLinkAsync in GenHub/GenHub.Core/Interfaces/Workspace/IFileOperationsService.cs, mirroring the existing CreateSymlinkAsync pattern.
• Update GenHub/GenHub.Windows/Features/Workspace/WindowsFileOperationsService.cs so CreateHardLinkAsync checks FileOperationsService.AreSameVolume and copies the file when volumes differ, and also catches the IOException whose message contains "different volumes" and copies, reusing the working pattern already present in LinkFromCasAsync.
• Update the base CreateHardLinkAsync in GenHub/GenHub/Features/Workspace/FileOperationsService.cs to accept the new parameter and keep its existing non-Windows copy behavior.
• Update HardLinkStrategy call sites to request fallback so the strategy relies on the shared implementation instead of only its inline try/catch.

🤖 Prompt for AI agents

Implement cross-volume hard-link copy fallback so workspace preparation succeeds
when the workspace root is on a different volume than the installation. Goal:
remove the hard abort and centralize the copy fallback.

- In `HardLinkStrategy.PrepareAsync`
(`GenHub/GenHub/Features/Workspace/Strategies/HardLinkStrategy.cs`), remove the
early return that sets `IsPrepared = false` and adds an Error-severity
`ValidationIssue` on volume mismatch.
- Let the per-file loop run for all cases. The loop must attempt a hard link
and, when the hard link fails due to a cross-volume condition, copy the file
instead.
- Keep same-volume behavior unchanged so same-volume hard-link efficiency is
preserved.
- Add an `allowFallback` parameter to `CreateHardLinkAsync` in
`GenHub/GenHub.Core/Interfaces/Workspace/IFileOperationsService.cs`, mirroring
the existing `CreateSymlinkAsync` pattern.
- In `GenHub/GenHub.Windows/Features/Workspace/WindowsFileOperationsService.cs`,
update `CreateHardLinkAsync` to check `FileOperationsService.AreSameVolume` and
copy the file when volumes differ. Also catch the `IOException` whose message
contains "different volumes" and copy in that case, reusing the pattern already
present in `LinkFromCasAsync`.
- Update the base `CreateHardLinkAsync` in
`GenHub/GenHub/Features/Workspace/FileOperationsService.cs` to accept the new
parameter and retain its existing non-Windows copy behavior.
- Update `HardLinkStrategy` call sites to request the fallback so the strategy
relies on the shared implementation rather than only its inline try/catch.

Phase 3: Recreate workspaces when the storage root changed

This phase prevents reuse of a workspace that lives under the previous protected root after storage resolution changes. It adds a root-mismatch check to the reuse path and cleans up the obsolete workspace.

Task 1: Detect a stale storage root during reuse

Add a root comparison to the workspace reuse decision.

• Update the reuse block in WorkspaceManager.PrepareWorkspaceAsync (GenHub/GenHub/Features/Workspace/WorkspaceManager.cs) to compute the expected path as Path.Combine(configuration.WorkspaceRootPath, configuration.Id).
• Compare the persisted workspace.WorkspacePath against the expected path using normalized, case-insensitive comparison (Path.TrimEndingDirectorySeparator, StringComparison.OrdinalIgnoreCase).
• On mismatch, log a warning and fall through to recreation instead of reusing the stale workspace.

Task 2: Clean up the obsolete workspace on root change

Remove the workspace under the old root when the root changed.

• When Task 3.1 detects a mismatch, call the existing cleanup path (CleanupWorkspaceAsync/directory deletion) for the stale workspace.WorkspacePath before strategy preparation, consistent with the current ForceRecreate cleanup behavior.
• Ensure metadata is overwritten with the newly resolved WorkspacePath via the existing SaveWorkspaceMetadataAsync path after recreation.

🤖 Prompt for AI agents

Implement stale-root detection and cleanup in `WorkspaceManager` so a workspace
persisted under an old root is not reused after storage resolution changes.
Goal: force recreation when the storage root changed.

- In the reuse block of `WorkspaceManager.PrepareWorkspaceAsync`
(`GenHub/GenHub/Features/Workspace/WorkspaceManager.cs`), compute the expected
path as `Path.Combine(configuration.WorkspaceRootPath, configuration.Id)`.
- Compare the persisted `workspace.WorkspacePath` against the expected path
using normalized, case-insensitive comparison
(`Path.TrimEndingDirectorySeparator`, `StringComparison.OrdinalIgnoreCase`).
- On mismatch, log a warning and fall through to recreation instead of reusing
the stale workspace.
- When a mismatch is detected, call the existing cleanup path
(`CleanupWorkspaceAsync`/directory deletion) for the stale
`workspace.WorkspacePath` before strategy preparation runs, consistent with the
current `ForceRecreate` cleanup behavior.
- After recreation, ensure metadata is overwritten with the newly resolved
`WorkspacePath` via the existing `SaveWorkspaceMetadataAsync` path.

Phase 4: Focused regression tests

This phase adds targeted tests for each behavior and keeps the Core test suite passing. Tests must not require real separate physical drives.

Task 1: Add StorageLocationService fallback tests

Verify path precedence and writability fallback.

• Add StorageLocationServiceTests.cs under GenHub/GenHub.Tests/GenHub.Tests.Core/Common/Services/, following the structure and mocking conventions in UserSettingsServiceTests.cs.
• Mock IUserSettingsService, IGameInstallationService, IConfigurationProviderService, and ILogger<StorageLocationService>.
• Cover: configured writable user path wins; writable installation-adjacent path is used when enabled; a non-writable adjacent path (simulated with a temp directory the probe cannot write to, or by pointing at a path that fails the probe) falls back to centralized application-data storage.

Task 2: Add HardLinkStrategy cross-volume copy test

Verify cross-volume files copy instead of failing.

• Add a focused test in GenHub/GenHub.Tests/GenHub.Tests.Core/Features/Workspace/StrategyTests.cs (or a new sibling test file) that runs HardLinkStrategy.PrepareAsync with BaseInstallationPath and WorkspaceRootPath on different roots.
• Gate the drive-letter assertion with OperatingSystem.IsWindows() or a Path.GetPathRoot comparison, following the conditional pattern in WorkspaceValidatorTests.ValidatePrerequisitesAsync_DifferentVolumes_ReturnsWarning.
• Assert that preparation succeeds (IsPrepared == true) and that files exist in the workspace, confirming the copy fallback ran.

Task 3: Add WorkspaceManager stale-root recreation test

Verify recreation when the persisted root differs.

• Extend GenHub/GenHub.Tests/GenHub.Tests.Core/Features/Workspace/WorkspaceManagerTests.cs, or add to WorkspaceIntegrationTests.cs, following the IConfigurationProviderService/IWorkspaceValidator stubbing and CasReferenceTracker/WorkspaceReconciler setup already used there.
• Prepare a workspace once, then call PrepareWorkspaceAsync again for the same Id with a different WorkspaceRootPath, and assert the manager recreates the workspace under the new root and does not reuse the old path.

🤖 Prompt for AI agents

Add focused regression tests for each behavior added in Phases 1-3. Goal: verify
the fallback, cross-volume copy, and stale-root recreation behaviors, and keep
the Core test suite passing. Tests must not require real separate physical
drives.

- Add `StorageLocationServiceTests.cs` under
`GenHub/GenHub.Tests/GenHub.Tests.Core/Common/Services/`, following the
structure and mocking conventions in `UserSettingsServiceTests.cs`. Mock
`IUserSettingsService`, `IGameInstallationService`,
`IConfigurationProviderService`, and `ILogger<StorageLocationService>`. Cover
these cases: a configured writable user path takes precedence; a writable
installation-adjacent path is used when enabled; a non-writable adjacent path
(simulate with a temp directory the probe cannot write to, or a path that fails
the probe) falls back to centralized application-data storage.
- Add a focused test in
`GenHub/GenHub.Tests/GenHub.Tests.Core/Features/Workspace/StrategyTests.cs` (or
a new sibling test file) that runs `HardLinkStrategy.PrepareAsync` with
`BaseInstallationPath` and `WorkspaceRootPath` on different roots. Gate any
drive-letter assertion with `OperatingSystem.IsWindows()` or a
`Path.GetPathRoot` comparison, following the conditional pattern in
`WorkspaceValidatorTests.ValidatePrerequisitesAsync_DifferentVolumes_ReturnsWarning`.
Assert that preparation succeeds (`IsPrepared == true`) and that files exist in
the workspace, confirming the copy fallback ran.
- Extend
`GenHub/GenHub.Tests/GenHub.Tests.Core/Features/Workspace/WorkspaceManagerTests.cs`,
or add to `WorkspaceIntegrationTests.cs`, following the existing
`IConfigurationProviderService`/`IWorkspaceValidator` stubbing and
`CasReferenceTracker`/`WorkspaceReconciler` setup used there. Prepare a
workspace once, then call `PrepareWorkspaceAsync` again for the same `Id` with a
different `WorkspaceRootPath`. Assert that the manager recreates the workspace
under the new root and does not reuse the old path.

Research

StorageLocationService (GenHub/GenHub/Common/Services/StorageLocationService.cs) resolves per-installation workspace and CAS paths. It switches only on the UserSettings.UseInstallationAdjacentStorage flag. It performs no writability check. It ignores the configured user paths that ConfigurationProviderService resolves.

WorkspaceManager (GenHub/GenHub/Features/Workspace/WorkspaceManager.cs) reuses or recreates workspaces by matching on WorkspaceConfiguration.Id only. It never compares the persisted WorkspaceInfo.WorkspacePath root against the freshly resolved root.

HardLinkStrategy (GenHub/GenHub/Features/Workspace/Strategies/HardLinkStrategy.cs) aborts with an Error-severity issue when the base installation and workspace roots differ. This happens before its existing per-file copy fallback can run.

A write-probe pattern already exists in WorkspaceValidator (Directory.CreateDirectory + temp-file write + delete).

The launch flow builds a WorkspaceConfiguration in ProfileLauncherFacade and GameLauncher. It assigns WorkspaceRootPath from StorageLocationService.GetWorkspacePath. It delegates preparation to WorkspaceManager.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement writable storage resolution with fallback in `StorageLocationService`
and `ConfigurationProviderService`. Goal: workspace and CAS path resolution must
always return a user-writable location, honoring configured paths first.

- In `GenHub/GenHub/Common/Services/StorageLocationService.cs`, add a private
writability probe method that mirrors the `WorkspaceValidator` pattern: call
`Directory.CreateDirectory`, write a temporary file, delete it, and return
`true` on success. Catch `UnauthorizedAccessException`, `IOException`, and
`SecurityException`; on any of these, log a warning and return `false`. The
probe must never throw to callers.
- Update `GetWorkspacePath(IGameInstallation)` to resolve paths in this
precedence order: (1) a user-configured writable path from
`IConfigurationProviderService.GetWorkspacePath()` when
`UserSettings.IsExplicitlySet(nameof(UserSettings.WorkspacePath))` is true and
the probe confirms writability; (2) the installation-adjacent path when
`UseInstallationAdjacentStorage` is true and it is writable; (3) the centralized
application-data workspace path as the final fallback.
- Update `GetCasPoolPath(IGameInstallation)` symmetrically, using
`IConfigurationProviderService.GetCasConfiguration().CasRootPath` for the
configured path and the centralized `%LocalAppData%/GenHub/cas-pool` path as the
final fallback.
- Inject `IConfigurationProviderService` into `StorageLocationService`. Verify
there is no dependency cycle (`ConfigurationProviderService` must not depend on
`IStorageLocationService`).
- Replace the hardcoded `"Workspaces"` literal with the appropriate
`DirectoryNames` constant.
- Log an informational message when the resolver falls back from an
installation-adjacent path to centralized storage.
- Update `ConfigurationProviderService.GetCasConfiguration()` to probe the
effective `CasRootPath` for writability and fall back to the application-data
default when the configured or default path is not writable. Reuse the probe
logic from the writability probe; if needed in both services, extract it into a
small shared helper in `GenHub/GenHub/Common/Services/` to avoid duplication.
Log a warning when the fallback is applied due to a non-writable configured CAS
path.
===============================================================================

Task: 2

Implement cross-volume hard-link copy fallback so workspace preparation succeeds
when the workspace root is on a different volume than the installation. Goal:
remove the hard abort and centralize the copy fallback.

- In `HardLinkStrategy.PrepareAsync`
(`GenHub/GenHub/Features/Workspace/Strategies/HardLinkStrategy.cs`), remove the
early return that sets `IsPrepared = false` and adds an Error-severity
`ValidationIssue` on volume mismatch.
- Let the per-file loop run for all cases. The loop must attempt a hard link
and, when the hard link fails due to a cross-volume condition, copy the file
instead.
- Keep same-volume behavior unchanged so same-volume hard-link efficiency is
preserved.
- Add an `allowFallback` parameter to `CreateHardLinkAsync` in
`GenHub/GenHub.Core/Interfaces/Workspace/IFileOperationsService.cs`, mirroring
the existing `CreateSymlinkAsync` pattern.
- In `GenHub/GenHub.Windows/Features/Workspace/WindowsFileOperationsService.cs`,
update `CreateHardLinkAsync` to check `FileOperationsService.AreSameVolume` and
copy the file when volumes differ. Also catch the `IOException` whose message
contains "different volumes" and copy in that case, reusing the pattern already
present in `LinkFromCasAsync`.
- Update the base `CreateHardLinkAsync` in
`GenHub/GenHub/Features/Workspace/FileOperationsService.cs` to accept the new
parameter and retain its existing non-Windows copy behavior.
- Update `HardLinkStrategy` call sites to request the fallback so the strategy
relies on the shared implementation rather than only its inline try/catch.
===============================================================================

Task: 3

Implement stale-root detection and cleanup in `WorkspaceManager` so a workspace
persisted under an old root is not reused after storage resolution changes.
Goal: force recreation when the storage root changed.

- In the reuse block of `WorkspaceManager.PrepareWorkspaceAsync`
(`GenHub/GenHub/Features/Workspace/WorkspaceManager.cs`), compute the expected
path as `Path.Combine(configuration.WorkspaceRootPath, configuration.Id)`.
- Compare the persisted `workspace.WorkspacePath` against the expected path
using normalized, case-insensitive comparison
(`Path.TrimEndingDirectorySeparator`, `StringComparison.OrdinalIgnoreCase`).
- On mismatch, log a warning and fall through to recreation instead of reusing
the stale workspace.
- When a mismatch is detected, call the existing cleanup path
(`CleanupWorkspaceAsync`/directory deletion) for the stale
`workspace.WorkspacePath` before strategy preparation runs, consistent with the
current `ForceRecreate` cleanup behavior.
- After recreation, ensure metadata is overwritten with the newly resolved
`WorkspacePath` via the existing `SaveWorkspaceMetadataAsync` path.
===============================================================================

Task: 4

Add focused regression tests for each behavior added in Phases 1-3. Goal: verify
the fallback, cross-volume copy, and stale-root recreation behaviors, and keep
the Core test suite passing. Tests must not require real separate physical
drives.

- Add `StorageLocationServiceTests.cs` under
`GenHub/GenHub.Tests/GenHub.Tests.Core/Common/Services/`, following the
structure and mocking conventions in `UserSettingsServiceTests.cs`. Mock
`IUserSettingsService`, `IGameInstallationService`,
`IConfigurationProviderService`, and `ILogger<StorageLocationService>`. Cover
these cases: a configured writable user path takes precedence; a writable
installation-adjacent path is used when enabled; a non-writable adjacent path
(simulate with a temp directory the probe cannot write to, or a path that fails
the probe) falls back to centralized application-data storage.
- Add a focused test in
`GenHub/GenHub.Tests/GenHub.Tests.Core/Features/Workspace/StrategyTests.cs` (or
a new sibling test file) that runs `HardLinkStrategy.PrepareAsync` with
`BaseInstallationPath` and `WorkspaceRootPath` on different roots. Gate any
drive-letter assertion with `OperatingSystem.IsWindows()` or a
`Path.GetPathRoot` comparison, following the conditional pattern in
`WorkspaceValidatorTests.ValidatePrerequisitesAsync_DifferentVolumes_ReturnsWarning`.
Assert that preparation succeeds (`IsPrepared == true`) and that files exist in
the workspace, confirming the copy fallback ran.
- Extend
`GenHub/GenHub.Tests/GenHub.Tests.Core/Features/Workspace/WorkspaceManagerTests.cs`,
or add to `WorkspaceIntegrationTests.cs`, following the existing
`IConfigurationProviderService`/`IWorkspaceValidator` stubbing and
`CasReferenceTracker`/`WorkspaceReconciler` setup used there. Prepare a
workspace once, then call `PrepareWorkspaceAsync` again for the same `Id` with a
different `WorkspaceRootPath`. Assert that the manager recreates the workspace
under the new root and does not reuse the old path.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!