Terminal locks its starting directory; perhaps it shouldn't do that?

Description of the new feature/enhancement

The directory that Windows Terminal starts up in can't be deleted (in Windows Explorer / Directory Opus / etc). It would be nice if I could delete the folder without exiting wt first.

Use case:

When you configure a profile to include this:
"startingDirectory" : ".",
and then set up the right-click "Start Windows Terminal Here" functionality in Windows Explorer to start a wt instance in any folder you get to create Terminal instances quickly and conveniently.

But, if you get done with that folder and want to delete it then you need to close wt first.

It would be convenient to delete the folder without closing wt first.

What's weird is that this behavior (keeping the starting dir locked so you can't delete it) continues to happen even if you navigate away from that dir in the command line.
(Which makes sense - wt creates new tabs in that same dir so preventing it from disappearing is understandable)

Proposed technical implementation details (optional)

• Do NOT lock the directory, allowing the user to delete it.
• Start new tabs in the default starting directory instead

maintainer edit:

Also using to track the thing where wt needs to tell the existing window about the current CWD, for running actions in an existing window (which may have a different CWD), see #13430

[zadjii-msft]

@MikePanitz-CCC If you tried doing the same thing in the legacy console (opening in a specific directory, navigating the shell away from that directory, then removing that directory), does the same thing happen?

I'd think that this would be the same behavior for all applications, where you can't remove the directory when a running process has that directory as it's current working directory, but I'm not 100% sure on that

Locking the dir that a shell is currently using be is reasonable. Keeping the wt starting dir locked as long as wt is running is awkward Xonsh in particular allows you to keep the dir unlocked. Get Outlook for Android<https://aka.ms/ghei36>

[DHowett-MSFT]

I don't disagree, but I do somewhat wonder how this'll interact with future uses of profiles with "startingDirectory": ".". Like: WT can move out of the directory it's in (since I think we're only locking it by virtue of it being our process's CWD), but then any new tab spawned with a profile set up like that will spawn in the wrong directory. We would need to pre-resolve all startingDirectories against the WD at the time of first settings load.

Then, at least those new tabs would error out ("can't find directory") instead of pointing at the wrong directory ...

That sounds completely reasonable to me.

FWIW:
cmd does not lock the dir when it leaves (I created a new dir, started a new CMD in that dir, had the new cmd do a "cd ..", and then deleted the new dir no problem)

powershell does lock the directory (I created a new dir is PS, cd'd to that new directory started powershell.exe in that new dir, had the original PS do a "cd ..", and then had the NEW powershell instance do a "cd ..", and was NOT able to delete the new dir.)
(I had the new ps.exe do an exit and was able to delete the new dir no problem which makes me very confident that the ps.exe was holding that dir open)

bash (from Git Bash - MinGW64) does not lock the current directory. At least, I was able to start a new bash process in the background ( bash & ) in a new dir, then switch back to my original bash process, have it cd out of the new dir, and then delete the new dir no problem.

What was really weird is that the child bash kept it's current working directory as being the folder I'd just deleted. When I asked it to do an 'ls' it reasonably said ls: cannot open directory '.': No such file or directory