Repository navigation
Windows: PowerShell reports a broken subst.exe drive as nonexistent #20894
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest released version
- Search the existing issues.
- Refer to the FAQ.
- Refer to Differences between Windows PowerShell 5.1 and PowerShell.
Steps to reproduce
Related:
However, the issue at hand isn't specific to v7.4.0 and dates back to Windows PowerShell.
# On Windows
# Establish a T: drive pointing to a temp. directory
subst T: /d 2>$null
subst T: ($dir = New-Item -Type Directory -Force "$env:TEMP:\$PID")
# Remove the temp. directory, which leaves T: in a broken state.
$dir | Remove-Item
# Try to get information about T:, which should still be possible
[System.IO.DriveInfo]::new('T')
Get-PSDrive TExpected behavior
Name : T:\
IsReady : False
RootDirectory : T:\
DriveType : NoRootDirectory
DriveFormat :
AvailableFreeSpace :
TotalFreeSpace :
TotalSize :
VolumeLabel :
CurrentLocation :
Name : T
Provider : Microsoft.PowerShell.Core\FileSystem
Root : T:\
Description :
MaximumSize :
Credential : System.Management.Automation.PSCredential
DisplayRoot :
VolumeSeparatedByColon : True
Used :
Free :Actual behavior
Name : T:\
IsReady : False
RootDirectory : T:\
DriveType : NoRootDirectory
DriveFormat :
AvailableFreeSpace :
TotalFreeSpace :
TotalSize :
VolumeLabel :
Get-PSDrive:
Line |
6 | Get-PSDrive T
| ~~~~~~~~~~~~~
| Cannot find drive. A drive with the name 'T' does not exist.That is, PowerShell now thinks the drive no longer exists, even though it still does, albeit in a broken state.
cmd /c dir T: doesn't complain about a missing drive, but a missing file (presumably the generic 0x2 system error that indicates a non-existent file or directory).
Error details
No response
Environment data
PowerShell 7.4.0 on Windows 11 22H2Visuals
No response
Activity
SteveL-MSFT commentedon Dec 11, 2023
I looked into this and what's happening is that https://learn.microsoft.com/en-us/dotnet/api/system.io.driveinfo.getdrives?view=net-8.0 doesn't return the broken drive so PowerShell has no knowledge of it. You should open an issue in dotnet/runtime to maybe have an overload of that method with flags if you think this is a useful scenario to get that info.
mklement0 commentedon Dec 11, 2023
Steve Lee (@SteveL-MSFT), from what I can tell, this .NET API does report the broken drive.
In the repro above, if you replace
[System.IO.DriveInfo]::new('T')with[System.IO.DriveInfo]::GetDrives(), you'll see thatT:is still there after the target dir. was removed.iSazonov commentedon Dec 11, 2023
I wonder why do we need the broken drive? PowerShell does the job better.
mklement0 commentedon Dec 11, 2023
Because users may want to know the difference between whether a drive exists and just happens to be - possibly temporarily - unavailable (e.g. #20861, though that particular case may be an outright bug) - and wether no such drive is defined.
It is inappropriate to ignore the existence of a drive just because it happens to be in a broken state - report the drive, and report an appropriate error on trying to access it (along the lines of "drive T: is not accessible")
In other words: Please remove the
Resolution-Externallabel and keep this issue open.mklement0 commentedon Dec 11, 2023