starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

"Open in Windows Terminal" keeps holding file handle #13243

New Issue
Closed
opened 2026-01-31 03:37:34 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 03:37:34 +00:00
Owner
Copy Link

Originally created by @RealMalWare on GitHub (Mar 30, 2021).

Windows Terminal version (or Windows build number)

1.6.2102.26001 + 1.7.2102.26002 (10.0.19042.0)

Other Software

No response

Steps to reproduce

Open Windows Terminal with shell extension "Open in Windows Terminal" in folder "newOrSthElse"
Leave folder "newOrSthElse" in Explorer
Try to delete folder in explorer "newOrSthElse" --> fails
Leave folder in Terminal Power Shell
Try to delete folder in explorer "newOrSthElse" --> fails
Close Terminal
Try to delete folder in explorer "newOrSthElse" --> OK

Expected Behavior

Windows Terminal / PowerShell must release the folder handle

Actual Behavior

Windows Terminal / PowerShell keeps the folder handle until closed

This behavior can not be reproduced with "Open in PowerShell"

ReleaseMe

ProcExp

(sorry for the german UI)

Originally created by @RealMalWare on GitHub (Mar 30, 2021). ### Windows Terminal version (or Windows build number) 1.6.2102.26001 + 1.7.2102.26002 (10.0.19042.0) ### Other Software _No response_ ### Steps to reproduce Open Windows Terminal with shell extension "Open in Windows Terminal" in folder "newOrSthElse" Leave folder "newOrSthElse" in Explorer Try to delete folder in explorer "newOrSthElse" --> fails Leave folder in Terminal Power Shell Try to delete folder in explorer "newOrSthElse" --> fails Close Terminal Try to delete folder in explorer "newOrSthElse" --> OK ### Expected Behavior Windows Terminal / PowerShell must release the folder handle ### Actual Behavior Windows Terminal / PowerShell keeps the folder handle until closed This behavior can not be reproduced with "Open in PowerShell" ![ReleaseMe](https://user-images.githubusercontent.com/39832934/113042065-0680e100-919b-11eb-828b-cb25386dda9a.gif) ![ProcExp](https://user-images.githubusercontent.com/39832934/113042092-0c76c200-919b-11eb-8e50-4522d04b5d69.png) (sorry for the german UI)
claunia added the Issue-QuestionNeeds-TriageNeeds-Tag-FixResolution-Answered labels 2026-01-31 03:37:34 +00:00
claunia commented 2026-01-31 03:37:35 +00:00
Author
Owner
Copy Link

@vefatica commented on GitHub (Mar 30, 2021):

This happens in consoles also, and unrelated to any shell context menu option. So I don't think it can be blamed on Windows Terminal.

In fact, Powershell's internal current working directory ($p in the prompt) seems to be diferent from Windows's notion of powershell's current directory (as returned by GetCurrentDirectory). That's little surprise since $p can show locations in the registry and other non-file system places.

After starting Powershell in v:\empty, and this

image

spying on powershell.exe reveals that GetCurrentDirectory still returns its start-up directory.

image

@vefatica commented on GitHub (Mar 30, 2021): This happens in consoles also, and unrelated to any shell context menu option. So I don't think it can be blamed on Windows Terminal. In fact, Powershell's internal current working directory ($p in the prompt) seems to be diferent from Windows's notion of powershell's current directory (as returned by GetCurrentDirectory). That's little surprise since $p can show locations in the registry and other non-file system places. After starting Powershell in v:\empty, and this ![image](https://user-images.githubusercontent.com/61856645/113045518-f520e000-916c-11eb-9667-c418af9d6d46.png) spying on powershell.exe reveals that GetCurrentDirectory still returns its start-up directory. ![image](https://user-images.githubusercontent.com/61856645/113045882-59dc3a80-916d-11eb-86d9-b962797e79c6.png)
claunia commented 2026-01-31 03:37:36 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 30, 2021):

Yea this seems like it's "This is working as designed, even if the design is perhaps unexpected"

@zadjii-msft commented on GitHub (Mar 30, 2021): Yea this seems like it's "This is working as designed, even if the design is perhaps unexpected"
claunia commented 2026-01-31 03:37:36 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 30, 2021):

Funny enough, though, this is duplicate of another bug on our tracker. I can't find it right now, but I recall the discussion I had with the filer. Ugh.

Terminal should get out of the way, so that even if you close the tab that did spawn in this folder you can still delete the folder.

@DHowett commented on GitHub (Mar 30, 2021): Funny enough, though, this is duplicate of another bug on our tracker. I can't find it right now, but I recall the discussion I had with the filer. Ugh. **Terminal should get out of the way, so that even if you close the tab that _did_ spawn in this folder you can still delete the folder.**
claunia commented 2026-01-31 03:37:36 +00:00
Author
Owner
Copy Link

@RealMalWare commented on GitHub (Mar 30, 2021):

Sorry, I did not find a matching issue.
It's not Terminal itseld hodling on to the folder, as you can see from the Process Explorer screenshot. Maybe it's the way PowerShell gets started. As I mentioned when right click opening PS in the folder there is no handle on that folder.

PSHandsOff

This issue bugged me a few times already. But feel free to close,as I like Terminal anyway :)

@RealMalWare commented on GitHub (Mar 30, 2021): Sorry, I did not find a matching issue. It's not Terminal itseld hodling on to the folder, as you can see from the Process Explorer screenshot. Maybe it's the way PowerShell gets started. As I mentioned when right click opening PS in the folder there is no handle on that folder. ![PSHandsOff](https://user-images.githubusercontent.com/39832934/113050605-4f3d9780-91a5-11eb-8ca9-121af05a3f9a.png) This issue bugged me a few times already. But feel free to close,as I like Terminal anyway :)
claunia commented 2026-01-31 03:37:36 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 30, 2021):

Interesting. Can you check the OpenConsole process that's running under Terminal? It may be that one.

@DHowett commented on GitHub (Mar 30, 2021): Interesting. Can you check the OpenConsole process that's running under Terminal? It may be that one.
claunia commented 2026-01-31 03:37:36 +00:00
Author
Owner
Copy Link

@RealMalWare commented on GitHub (Mar 30, 2021):

OpenConsole only has c:\windows\system32

Should have checked earlier - the command line for PowerShell's shell extension differs slightly :). This also works when calling directly from Win+R.

PowerShell.exe -noexit -command Set-Location -literalPath 'C:\temp\new'

The working/current directory seems to be C:\Windows\System32\WindowsPowerShell\v1.0 in that case.

commandLine

@RealMalWare commented on GitHub (Mar 30, 2021): OpenConsole only has c:\windows\system32 Should have checked earlier - the command line for PowerShell's shell extension differs slightly :). This also works when calling directly from Win+R. ``` PowerShell.exe -noexit -command Set-Location -literalPath 'C:\temp\new' ``` The working/current directory seems to be C:\Windows\System32\WindowsPowerShell\v1.0 in that case. ![commandLine](https://user-images.githubusercontent.com/39832934/113057741-b7907700-91ad-11eb-92a6-a228c9aaa69f.png)
claunia commented 2026-01-31 03:37:36 +00:00
Author
Owner
Copy Link

@vefatica commented on GitHub (Mar 30, 2021):

Looks different here (V: is a subst for d:\work).

image

It seems powershell will always have a handle to its start-up directory (unless there's a way to get it to SetCurrentDirectory() to something else).

In a few tests, I've seen openconsole.exe with a variety of CWDs. They seem to depend on how I start Windows Terminal and which one I start; the WT alias now points to the preview and I also have an unpackaged install of the preview. Openconsole.exe's CWD doesn't seem to have anything to do with the CWD or start-up directory of the app it's hosting.

@vefatica commented on GitHub (Mar 30, 2021): Looks different here (V: is a subst for d:\work). ![image](https://user-images.githubusercontent.com/61856645/113053477-4da8ab00-9176-11eb-8a90-546c61a2aa9c.png) It seems powershell will always have a handle to its start-up directory (unless there's a way to get it to SetCurrentDirectory() to something else). In a few tests, I've seen openconsole.exe with a variety of CWDs. They seem to depend on how I start Windows Terminal and which one I start; the WT alias now points to the preview and I also have an unpackaged install of the preview. Openconsole.exe's CWD doesn't seem to have anything to do with the CWD or start-up directory of the app it's hosting.
claunia commented 2026-01-31 03:37:37 +00:00
Author
Owner
Copy Link

@vefatica commented on GitHub (Mar 31, 2021):

FWIW, you can, in PowerShell, for example,

[System.IO.Directory]::SetCurrentDirectory("c:\windows\system32\")

That willl free the handle to it's start-up directory. I put that command in my PROFILE.PS1. PowerShell still starts in the expected place and after leaving the start-up directory, it can be removed (provided no other reasons prevent it).

@vefatica commented on GitHub (Mar 31, 2021): FWIW, you can, in PowerShell, for example, `[System.IO.Directory]::SetCurrentDirectory("c:\windows\system32\")` That willl free the handle to it's start-up directory. I put that command in my PROFILE.PS1. PowerShell still starts in the expected place and after leaving the start-up directory, it can be removed (provided no other reasons prevent it).
claunia commented 2026-01-31 03:37:37 +00:00
Author
Owner
Copy Link

@vefatica commented on GitHub (Mar 31, 2021):

You can also investigate without a third-party tool.

image

@vefatica commented on GitHub (Mar 31, 2021): You can also investigate without a third-party tool. ![image](https://user-images.githubusercontent.com/61856645/113211066-f9b7c800-9242-11eb-9fd0-d292b336b63c.png)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Question Needs-Tag-Fix Needs-Triage Resolution-Answered
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#13243
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?