Windows Terminal leaks a file handle to the starting directory #14762

@vefatica commented on GitHub (Aug 2, 2021):

It's still the current working directory of windowsterminal.exe and openconsole.exe.

@vefatica commented on GitHub (Aug 2, 2021): It's still the current working directory of windowsterminal.exe and openconsole.exe.

claunia commented

@zomgrolf commented on GitHub (Aug 2, 2021):

Possibly, so?

@zomgrolf commented on GitHub (Aug 2, 2021): Possibly, so?

claunia commented

@vefatica commented on GitHub (Aug 2, 2021):

A process always has an open handle to its current working directory.

@vefatica commented on GitHub (Aug 2, 2021): A process always has an open handle to its current working directory.

claunia commented

@zomgrolf commented on GitHub (Aug 2, 2021):

And the current working directory stays the same forever because...?

@zomgrolf commented on GitHub (Aug 2, 2021): And the current working directory stays the same forever because...?

claunia commented

@eryksun commented on GitHub (Aug 2, 2021):

A process keeps its working directory open without shared delete access, which prevents the directory from being deleted or renamed until the directory is closed (e.g. the working directory changes or the process terminates). Notably, the base API uses the handle for the working directory to open relative file paths (see NTAPI OBJECT_ATTRIBUTES RootDirectory), which is similar to openat() in POSIX systems.

And the current working directory stays the same forever because...?

Because "WindowsTerminal.exe" and "OpenConsole.exe" never change their inherited working directory? I guess they could change it to the system directory.

@eryksun commented on GitHub (Aug 2, 2021): A process keeps its working directory open without shared delete access, which prevents the directory from being deleted or renamed until the directory is closed (e.g. the working directory changes or the process terminates). Notably, the base API uses the handle for the working directory to open relative file paths (see NTAPI [`OBJECT_ATTRIBUTES`](https://docs.microsoft.com/en-us/windows/win32/api/ntdef/ns-ntdef-_object_attributes) `RootDirectory`), which is similar to `openat()` in POSIX systems. > And the current working directory stays the same forever because...? Because "WindowsTerminal.exe" and "OpenConsole.exe" never change their inherited working directory? I guess they could change it to the system directory.

claunia commented

@vefatica commented on GitHub (Aug 2, 2021):

I think there are situations in which windowsterminal.exe changes its CWD ... using "Open in Windows Terminal" with a re-used instance. IIRC, folks wanted new shells opened in "." to follow the "open in" mechanism around. (yes/no?)

@vefatica commented on GitHub (Aug 2, 2021): I think there are situations in which windowsterminal.exe changes its CWD ... using "Open in Windows Terminal" with a re-used instance. IIRC, folks wanted new shells opened in "." to follow the "open in" mechanism around. (yes/no?)

claunia commented

@zadjii-msft commented on GitHub (Aug 2, 2021):

That's correct. When you've got the windowing behavior set to re-use an existing window (the second two options here:

), or when you do a wt -w N -- whatever.exe, we'll have the wt opening the commandline switch to the CWD of the source of the commandline, spawn that connection, then switch back. This is to make sure profiles that have their startingDirectory set to something like . work correctly.

@zadjii-msft commented on GitHub (Aug 2, 2021): That's correct. When you've got the windowing behavior set to re-use an existing window (the second two options here: ![image](https://user-images.githubusercontent.com/18356694/127900338-8165b523-78e7-44e4-920b-5f9eb786efeb.png) ), or when you do a `wt -w N -- whatever.exe`, we'll have the `wt` opening the commandline switch to the CWD of the source of the commandline, spawn that connection, then switch back. This is to make sure profiles that have their `startingDirectory` set to something like `.` work correctly.

claunia commented

@zomgrolf commented on GitHub (Aug 2, 2021):

So how do I force Windows Terminal to change the current working directory when I change the directory in the command prompt?

@zomgrolf commented on GitHub (Aug 2, 2021): So how do I force Windows Terminal to change the current working directory when I change the directory in the command prompt?

claunia commented

@vefatica commented on GitHub (Aug 2, 2021):

So how do I force Windows Terminal to change the current working directory when I change the directory in the command prompt?

The short answer is you can't. Why would you want to?

@vefatica commented on GitHub (Aug 2, 2021): > So how do I force Windows Terminal to change the current working directory when I change the directory in the command prompt? The short answer is you can't. Why would you want to?

claunia commented

@zomgrolf commented on GitHub (Aug 2, 2021):

Consider the following scenario:

A developer launches the terminal from a directory that contains some build artifacts (e.g. CMake configuration cache or maybe some other files generated as a part of the build process, or perhaps not even build artifacts, it doesn't really matter). She or he does some work on the command line in that directory, then switches away to another directory on the filesystem.
Over the course of the next hour(s), said developer launches a number of other terminal windows (possibly with tabs), working on some other (maybe related, maybe not) things in other areas of the filesystem.
At some point (s)he decides to build the first project. Or maybe hands over the machine to another developer who needs to do a full rebuild. In this case, certain builds are done from scratch and involve wiping clean the entire build area and resyncing the source code and all dependencies. And so that other developer triggers a full rebuild -- except now the part that does the cleanup mysteriously fails, although it used to work fine. It's not immediately obvious what is the cause and why that directory could not be deleted -- it doesn't contain any executables/dlls that could be locked by a running process, none of the open command prompts have it set as their current directory.

That's because someone else started the terminal from that directory a few hours ago.

At this point your option is to look for the handle, then try to match the PID of the process that owns it with the right instance of the terminal and close it, otherwise you won't be able run the automated build process. Not the best user experience.

And if that first terminal was actually used to start some long running process (e.g. a regression suite for another build configuration, 8+ hours total and you're on hour 4), then you're out of luck.

Mind you, all of this works with the old conhost just fine -- there are no issues with deleting the starting directory, so from our point of view, this is effectively a regression.

Not sure how it fits with the plans for making Windows Terminal the default terminal in the future.

@zomgrolf commented on GitHub (Aug 2, 2021): Consider the following scenario: 1. A developer launches the terminal from a directory that contains some build artifacts (e.g. CMake configuration cache or maybe some other files generated as a part of the build process, or perhaps not even build artifacts, it doesn't really matter). She or he does some work on the command line in that directory, then switches away to another directory on the filesystem. 2. Over the course of the next hour(s), said developer launches a number of other terminal windows (possibly with tabs), working on some other (maybe related, maybe not) things in other areas of the filesystem. 3. At some point (s)he decides to build the first project. Or maybe hands over the machine to another developer who needs to do a full rebuild. In this case, certain builds are done from scratch and involve wiping clean the entire build area and resyncing the source code and all dependencies. And so that other developer triggers a full rebuild -- except now the part that does the cleanup mysteriously fails, although it used to work fine. It's not immediately obvious what is the cause and why that directory could not be deleted -- it doesn't contain any executables/dlls that could be locked by a running process, none of the open command prompts have it set as their current directory. That's because someone else started the terminal from that directory a few hours ago. At this point your option is to look for the handle, then try to match the PID of the process that owns it with the right instance of the terminal and close it, otherwise you won't be able run the automated build process. Not the best user experience. And if that first terminal was actually used to start some long running process (e.g. a regression suite for another build configuration, 8+ hours total and you're on hour 4), then you're out of luck. Mind you, all of this works with the old conhost just fine -- there are no issues with deleting the starting directory, so from our point of view, this is effectively a regression. Not sure how it fits with the plans for making Windows Terminal the default terminal in the future.

claunia commented

@zomgrolf commented on GitHub (Aug 2, 2021):

Now, it doesn't have to actually track the changes to the current directory in the shell. If there were an option to launch the terminal with the current working directory set to say, the system directory, but the current directory in the shell set to ".", then that would work just fine for me...

@zomgrolf commented on GitHub (Aug 2, 2021): Now, it doesn't have to actually track the changes to the current directory in the shell. If there were an option to launch the terminal with the current working directory set to say, the system directory, but the current directory in the shell set to ".", then that would work just fine for me...

claunia commented

@vefatica commented on GitHub (Aug 2, 2021):

Now, it doesn't have to actually track the changes to the current directory in the shell. If there were an option to launch the terminal with the current working directory set to say, the system directory, but the current directory in the shell set to ".", then that would work just fine for me...

I'm not sure what you're saying. If the terminal's CWD is the system directory, what is "."?

@vefatica commented on GitHub (Aug 2, 2021): > Now, it doesn't have to actually track the changes to the current directory in the shell. If there were an option to launch the terminal with the current working directory set to say, the system directory, but the current directory in the shell set to ".", then that would work just fine for me... I'm not sure what you're saying. If the terminal's CWD is the system directory, what is "."?

claunia commented

@DHowett commented on GitHub (Aug 2, 2021):

Terminal already has some provisions for caching that it thinks the current working directory should be, and it already forcibly resolves relative paths. It would be trivial for us to:

Save the current WD as a path
Change the WD to System32 or something
Never call GetCurrentDirectoryW, and always rely on the saved value.

This would allow us to unlock the working directory and still work normally.

@DHowett commented on GitHub (Aug 2, 2021): Terminal already has some provisions for caching that it *thinks* the current working directory should be, and it already forcibly resolves relative paths. It would be trivial for us to: 1. Save the current WD as a path 2. Change the WD to System32 or something 3. Never call GetCurrentDirectoryW, and always rely on the saved value. This would allow us to unlock the working directory _and_ still work normally.

claunia commented

@zomgrolf commented on GitHub (Aug 2, 2021):

Now, it doesn't have to actually track the changes to the current directory in the shell. If there were an option to launch the terminal with the current working directory set to say, the system directory, but the current directory in the shell set to ".", then that would work just fine for me...

I'm not sure what you're saying. If the terminal's CWD is the system directory, what is "."?

The directory from which I want to launch the terminal. In the example at the top of the thread it is c:\temp\rmdir_test -- that's where I want to start my shell -- meanwhile, the current working directory for the Windows Terminal process (which apparently, does not matter to me in this scenario) should be set to the system directory.

@zomgrolf commented on GitHub (Aug 2, 2021): > > Now, it doesn't have to actually track the changes to the current directory in the shell. If there were an option to launch the terminal with the current working directory set to say, the system directory, but the current directory in the shell set to ".", then that would work just fine for me... > > I'm not sure what you're saying. If the terminal's CWD is the system directory, what is "."? The directory from which I want to launch the terminal. In the example at the top of the thread it is `c:\temp\rmdir_test` -- that's where I want to start my shell -- meanwhile, the current working directory for the Windows Terminal process (which apparently, does not matter to me in this scenario) should be set to the system directory.

claunia commented

@zomgrolf commented on GitHub (Aug 2, 2021):

Again, when I launch a new instance of the terminal from an arbitrary directory, I want either:

For the CWD of the terminal process to track the current directory in the shell as I navigate around the file system, or:
To set that CWD to something other than the starting directory (while still starting the shell in that directory), preferably the system directory, since I will never, ever want to delete that.

The reason is that, currently, if you launch the terminal from an arbitrary directory, you cannot delete it until you close that instance of the terminal, and for various reasons you might actually want to delete it at some point. This is even more confusing, if you started your terminal some time ago (or, for example, it was launched by someone else the previous week), because there is absolutely nothing in the UI that indicates/reminds you that this is the case.

@zomgrolf commented on GitHub (Aug 2, 2021): Again, when I launch a new instance of the terminal from an arbitrary directory, I want either: 1. For the CWD of the terminal process to track the current directory in the shell as I navigate around the file system, or: 2. To set that CWD to something *other* than the starting directory (while still starting the shell in that directory), preferably the system directory, since I will never, ever want to delete that. The reason is that, currently, if you launch the terminal from an arbitrary directory, you cannot delete it until you close that instance of the terminal, and for various reasons you might actually want to delete it at some point. This is even more confusing, if you started your terminal some time ago (or, for example, it was launched by someone else the previous week), because there is **absolutely nothing** in the UI that indicates/reminds you that this is the case.

claunia commented

@zadjii-msft commented on GitHub (Aug 2, 2021):

Okeydokey well it seems like Dustin's got a good idea up in https://github.com/microsoft/terminal/issues/10849#issuecomment-891245118 so let's just do that.

@zadjii-msft commented on GitHub (Aug 2, 2021): Okeydokey well it seems like Dustin's got a good idea up in https://github.com/microsoft/terminal/issues/10849#issuecomment-891245118 so let's just do that.

claunia commented

@vefatica commented on GitHub (Aug 2, 2021):

I think that's what @DHowett is talking about. It'd probably also make sense to ensure that OpenConsole.exe's CWD is something innocuous.

Off-topic, but somewhat interesting ... I never noticed until today that when a console is started, conhost.exe's CWD is c:\windows.

You can get some dicey situations in a console. Start a CMD.EXE console with CWD = directory_A. At the CMD prompt, issue CMD and then issue CD /D directory_B. Hand the machine over to someone else, and he won't be able to remove directory_A.

@vefatica commented on GitHub (Aug 2, 2021): I think that's what @DHowett is talking about. It'd probably also make sense to ensure that OpenConsole.exe's CWD is something innocuous. Off-topic, but somewhat interesting ... I never noticed until today that when a console is started, conhost.exe's CWD is c:\windows. You can get some dicey situations in a console. Start a CMD.EXE console with CWD = directory_A. At the CMD prompt, issue `CMD` and then issue `CD /D directory_B`. Hand the machine over to someone else, and he won't be able to remove directory_A.

claunia commented