VSCode Extension v2022.8.5 initializes wrong user profile path

[Adwaenyth]

Prerequisites

• I have written a descriptive issue title.
• I have searched all open and closed issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

On a system with folder redirection for $env:AppData Folder to a UNC Path, the PowerShell extension does not resolve that path correctly on startup.

PowerShell Version

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.2.6
PSEdition                      Core
GitCommitId                    7.2.6
OS                             Microsoft Windows 10.0.19044
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visual Studio Code Version

code --version
1.72.0
64bbfbf67ada9953918d72e1df2f4d8e537d340e
x64

Extension Version

code --list-extensions --show-versions | select-string powershell

ms-vscode.powershell@2022.8.5

Steps to Reproduce

The Extension creates the initial session files in C:\<shareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\sessions\PSES-VSCode-<ID>.json and the intial log Folders in C:\<shareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID> on the local harddrive.

After creating these files however, the extension tries to use at least the log files from the UNC share (which aren't present there) and creates a partial log for the respective session in \\<ServerName>\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID>.

The initial call from the VS Code Terminal Console invokes a scriptblock like this : Import-Module 'c:\Users\<UserName>\.vscode\extensions\ms-vscode.powershell-2022.8.5\modules\PowerShellEditorServices\PowerShellEditorServices.psd1'; Start-EditorServices -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2022.8.5' -AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'c:\Users\<UserName>\.vscode\extensions\ms-vscode.powershell-2022.8.5\modules' -EnableConsoleRepl -StartupBanner "<BannerText>" -LogLevel 'Normal' -LogPath '\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID>\EditorServices.log' -SessionDetailsPath '\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\sessions\PSES-VSCode-<ID>.json' -FeatureFlags @()

Instead of what I believe would be correct:

Import-Module 'c:\Users\<UserName>\.vscode\extensions\ms-vscode.powershell-2022.8.5\modules\PowerShellEditorServices\PowerShellEditorServices.psd1'; Start-EditorServices -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '2022.8.5' -AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'c:\Users\<UserName>\.vscode\extensions\ms-vscode.powershell-2022.8.5\modules' -EnableConsoleRepl -StartupBanner "<BannerText>" -LogLevel 'Normal' -LogPath '\\<ServerName>\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID>\EditorServices.log' -SessionDetailsPath '\\<ServerName>\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\sessions\PSES-VSCode-<ID>.json' -FeatureFlags @()

Visuals

No response

Logs

No response

[andyleejordan]

Hm...this may be an upstream problem with VS Code. As far as I can tell we're using the URIs and APIs correctly. We start with passing vscode.ExtensionContext.globalStorageUri to the logger:

vscode-powershell/src/main.ts

Line 124 in 3f98265

logger = new Logger(context.globalStorageUri);

That's used to create the directory logging directory here:

vscode-powershell/src/logging.ts

Lines 137 to 147 in 3f98265

	public async startNewLog(minimumLogLevel: string = "Normal"): Promise<void> {
	this.MinimumLogLevel = this.logLevelNameToValue(minimumLogLevel.trim());
	this.logSessionPath =
	vscode.Uri.joinPath(
	this.logBasePath,
	`${Math.floor(Date.now() / 1000)}-${vscode.env.sessionId}`);
	this.logFilePath = this.getLogFilePath("vscode-powershell");
	await vscode.workspace.fs.createDirectory(this.logSessionPath);
	}

Which is both joining URIs (no conversion to file paths) and passing the URI to vscode.workspace.fs.createDirectory. Yet as you indicated, you see that directory get incorrectly created at C:\<shareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID> instead of \\<ServerName>\<ShareName>\<UserName>\AppData\Roaming\Code\User\globalStorage\ms-vscode.powershell\logs\<RandomID>.

We then pass that URI to the server (what you see in the list of arguments):

vscode-powershell/src/process.ts

Line 54 in 3f98265

`-LogPath '${PowerShellProcess.escapeSingleQuotes(editorServicesLogPath.fsPath)}' ` +

We explicitly use the fsPath property of the URI which says its correctly handles UNC paths. I don't think the issue is the \ vs \\, as we're directly using the fsPath value, but that the first createDirectory API call takes the URI and then puts C:\ on it, instead of handling the UNC share path.

@TylerLeonhardt any ideas?

[TylerLeonhardt]

I would like to know the value of this.logSessionPath before it gets passed to createDirectory. If it's \ then the bug is before it... since it will create it under C:. If it's \\ and it's still creating it under C: that's a bug in createDirectory.

[andyleejordan]

It's:

this.logSessionPath = 
         vscode.Uri.joinPath( 
             this.logBasePath, 
             `${Math.floor(Date.now() / 1000)}-${vscode.env.sessionId}`);

and this.logBasePath is vscode.Uri.joinPath(logBasePath, "logs"); and finally logBasePath is context.globalStorageUri for an equivalent of:

vscode.Uri.joinPath(context.globalStorageUri, "logs", "<RandomID>")

[TylerLeonhardt]

Sure but I'm just saying it could be the joinPath that's messing up... or maybe the globalStorageUri is just totally wrongly represented.

[Adwaenyth]

After digging a little bit into it, it seems that the initially created session files are also not being created in the correct directory.

The session files directory actually does not get created - however if I create the directory sessions manually in the directory on the local hard drive path, the session files get created there. If I create that folder on the UNC share, no session files get created.

The extension then however still cannot access the session .json file. The part of the log that is being created on the UNC share then states:

11.10.2022 07:15:59 [NORMAL] - PowerShell executable: C:\Program Files\PowerShell\7\pwsh.exe
11.10.2022 07:15:59 [NORMAL] - pwsh.exe started.
11.10.2022 07:20:02 [ERROR] - Error: Timed out waiting for session file to appear!

The on the log-path that is created on the local hard drive two empty log files get created EditorServices.log and StartEditorServices.log.

I'm attaching the files of the most recent startup attempt that do get created along with the output of the visual studio extension logs.

local_hard_drive_session_file.zip
unc_share_log_vscode-powershell.zip
vs_code_extension_log_output.txt

Are the globalStorage paths evaluted differently during the extension startup?

[andyleejordan]

Sure but I'm just saying it could be the joinPath that's messing up... or maybe the globalStorageUri is just totally wrongly represented.

Yeah but these are both VS Code APIs 😆 I'll step through an extension startup on Windows later today and see what I can get you, though I don't have a UNC share so I'll have to set that up...somehow. Actually @Adwaenyth how the heck do you have a UNC path for AppData?!

[Adwaenyth]

@andschwa The AppData folder can be redirected (and is in my case) via GPO (User Settings -> Windows Settings -> Folder Redirection -> AppData(Roaming)). That in turn activates folder sync and sets the registry key for the AppData folder HKCU\Software\Microsoft\Windows NT\CurrentVersion\Explorer\User Shell Folders to the UNC path.

Programs usually accept this fine. On occasion I've seen some installers struggle with that too, but main reason for that so far was having hardcoded directory paths like C:\Users\ etc.

[andyleejordan]

@Adwaenyth would you be able to debug in your environment and check the value of the variable @TylerLeonhardt asked about above?

[Adwaenyth]

@andschwa @TylerLeonhardt to continue working on my project, I had had the group policy removed that enforced folder redirection for the %AppData% folder. With that removed, it went back to normal and the local %UserProfile%\AppData\Roaming folder on my harddrive was again used for the globalStorageUri without any issues.

I don't know when I'll get around to set up a test machine to reproduce the issue. All I can do atm is tell you the value the RegistryKey HKCU\Software\Microsoft\Windows NT\CurrentVersion\Explorer\User Shell Folders had a Value for AppData was set to a UNC path like \\<Server>\<ShareName>\AppData\Roaming\.

It might be different, if there's an actual drive letter mapped to that share instead of a UNC path.

To setup folder redirection and offline files for user profile folders via Group Policy this article https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-folder-redirection is maybe a hint.

PS: Since there were write actions to both the correct share name and the incorrect local hard drive folder, I'd think that in one place combining the path variable caused the issue, because I doubt that the value for gobalStorageUri changed during runtime. However currently I can't give you the value that was stored in the gobalStorageUri when the error happened.

Currently I'd suggest to avoid using folder redirection for AppData folder.