feat(powershell): open projects folder on a Dev Drive when present - #718
Merged
Conversation
Add Get-DevDrivePath/Get-ProjectsPath to DotfilesHelpers so the PowerShell profile cds into the Dev Drive projects folder instead of %USERPROFILE%\projects when a Dev Drive (fixed ReFS volume) exists. DEV_DRIVE pins a volume, PROJECTS_PATH overrides the folder outright. The Windows run_once setup script now creates the projects folder on the Dev Drive. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: af6ad983-307e-490a-adc1-d9e30131dadd
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
1 participant
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.
Source code on the NTFS system drive is subject to real-time antivirus scanning and generally slower IO than a Dev Drive, the ReFS volume Windows 11 provides specifically for developer workloads. Until now the PowerShell profile always dropped you in
%USERPROFILE%\projects, so having a Dev Drive did nothing for the shell.Approach
A new
DevDrive.ps1in theDotfilesHelpersmodule resolves the projects folder in this order:$env:PROJECTS_PATH, when set<Dev Drive>\projects, when a Dev Drive has one%USERPROFILE%\projectsprofile.ps1now callsGet-ProjectsPathfor the startupcd(theImport-Modulewas moved above that block so the function is available), and the Windowsrun_once_before_00-setup.ps1creates the projects folder on the Dev Drive when one is present. Unix shell configs are untouched, since Dev Drive is Windows-only.Non-obvious bits worth reviewing
fsutil devdrv queryis the authoritative check but requires an elevated shell, which a profile never has (verified: it returns "Access is denied" unelevated). Fixed, ready ReFS volumes are used instead, which is correct on a normal workstation but would false-positive on a plain ReFS data volume.$env:DEV_DRIVEpins a specific volume and$env:PROJECTS_PATHskips detection entirely.Get-ProjectsPathonly creates directories under the opt-in-CreateIfMissingswitch, so startup cost stays at an in-memoryDriveInfoenumeration with no CIM call.DotfilesHelpersfails to import, the profile falls back to the old%USERPROFILE%\projectsbehavior rather than erroring.DevDrive.ps1is intentionally unsigned; thesign-powershell.ymlworkflow signs it after merge.Testing
New
tests/powershell/DevDrive.Tests.ps1covers both env var overrides, the Dev Drive hit, the user-profile fallback, and that nothing is created without-CreateIfMissing.Profile.Tests.ps1gained an ordering assertion so the module import can't drift back below thecdblock. 188 tests pass across the affected files; PSScriptAnalyzer reports no new warnings.Docs: new "Projects folder and Dev Drive" section in
customization.md, plus a pointer from the Windows install steps.