Add configurable storage path for the default wslc session#40956
Add configurable storage path for the default wslc session#40956benhillis wants to merge 7 commits into
Conversation
The default wslc CLI session always created its storage VHD under %LOCALAPPDATA%\wslc\sessions, which is a problem when the system drive is small. Add a `session.storagePath` setting (settings.yaml) that lets users redirect the default session's storage to another location (e.g. a larger data drive). The value must be an absolute path; relative/empty values are rejected and fall back to %LOCALAPPDATA%. Named (custom) sessions are unaffected since they already accept an explicit path. Fixes #40953 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Adds a new session.storagePath user setting to allow redirecting the default wslc session’s storage location away from %LOCALAPPDATA%, while preserving the existing wslc\sessions\<session> layout under the configured base directory.
Changes:
- Introduced
session.storagePathinWSLCUserSettings(mapping + validation) and documented it in the settings template. - Updated default-session construction in
WSLCSessionManagerto use the configured storage base when present (otherwise%LOCALAPPDATA%). - Added unit tests covering absent/default/absolute/relative-invalid cases for the new setting.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| test/windows/wslc/WSLCCLISettingsUnitTests.cpp | Adds unit tests for session.storagePath parsing/validation and updates the “all known keys” test input. |
| src/windows/service/exe/WSLCSessionManager.cpp | Uses session.storagePath as the base for default session storage path resolution. |
| src/windows/common/WSLCUserSettings.h | Adds the new setting enum entry and YAML path mapping for session.storagePath. |
| src/windows/common/WSLCUserSettings.cpp | Documents session.storagePath in the settings template and validates it as a non-empty absolute path. |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
dkbennett
left a comment
dkbennett
left a comment
There was a problem hiding this comment.
LGTM. Do we have any runtime validation for the storage path both existing and having correct permissions to be accessible to the user, or does that surface as a session error when we attempt to use it?
OneBlue
left a comment
OneBlue
left a comment
There was a problem hiding this comment.
Do we want to expose this as a configuration key ? One downside of doing this is that changing this path will essentially drop everything that the user has.
One alternative we considered was to tell users to symlink their storage folder instead. This has the benefit of explicitly requiring user action, and so the user can also move their storage while they're doing it
Definitely one downside of this approach. I'm not a huge fan of the symlink approach. This one needs a little more UX thought but I think we really need to come up with a solution here. |
I discussed this @dkbennett a bit and there's definitely downsides to both. I think this implementation is OK for now. If users modify the settings I think the storage being reset is a reasonable UX. We can refine later if needed |
…session storage Surfaces a one-time warning on default-session creation when session.storagePath is set and an existing session exists at the default %LOCALAPPDATA% location but not yet at the configured one, so users are not surprised by their previous session/containers/images not being migrated. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Drop unneeded MultiByteToWide in the SessionStoragePath validator (std::filesystem::path constructs from std::string and is_absolute only inspects the root) and clarify the settings template to show the full per-session VHD path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
validate-localization.py enforces a canonical comment derived from auto-detected tokens; a manual {Locked=...} for a non-argument token (session.storagePath) diverges from the expected comment and fails CI. Use the canonical comment.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Per PR review, the literal setting key should not be translated. Append a Locked token after the canonical comment so the validator canonical substring stays intact. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Per PR feedback (dkbennett, benhillis), drop the default-vs-configured orphan detection. Warn once when creating a session VHD at a non-default storagePath, and document the orphan-on-change behavior in the settings template comment. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Summary
The default wslc CLI session always created its
storage.vhdxunder%LOCALAPPDATA%\wslc\sessions\<session>, which is a pain when the system drive is small. This adds asession.storagePathsetting so users can redirect the default session's storage to another location (e.g. a larger data drive).Resolves to
D:\wslc\wslc\sessions\<session>\storage.vhdx, mirroring the existing layout. When the key is absent or set todefault, behavior is unchanged (%LOCALAPPDATA%). Named (custom) sessions are unaffected, they already accept an explicit storage path.Fixes #40953
Details
WSLCUserSettings.h/.cpp: newSessionStoragePathsetting (session.storagePath), validated as a non-empty absolute path (relative/empty rejected, falls back to the default), plus a documented entry in the settings-file template.WSLCSessionManager.cpp:SessionSettings::Defaultuses the configured base when set, otherwise%LOCALAPPDATA%. The downstream VHD plumbing was already path-driven, so no further wiring was needed.Testing
WSLCCLISettingsUnitTests.cppcover absent, absolute,default, and relative-rejected cases, plus the all-known-keys no-warning check./WX:common.lib,wslservice.exe,wslc.exe,wsltests.dll.clang-formatclean on all changed files.Note: the validation only checks that the path is absolute; if the path is not writable by the user, session creation surfaces the underlying error at VHD-attach time (same as the existing custom-session path).