Change:
import { memoize } from 'vs/base/common/decorators'; import { join } from 'vs/base/common/path'; import { isLinux } from 'vs/base/common/platform'; <ins> import { URI } from 'vs/base/common/uri'; </ins> import { createStaticIPCHandle } from 'vs/base/parts/ipc/node/ipc.net'; import { IEnvironmentService, INativeEnvironmentService } from 'vs/platform/environment/common/environment'; import { NativeEnvironmentService } from 'vs/platform/environment/node/environmentService';

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.81.1 OS Version: server 2022 Steps to Reproduce: is a system install. Users login using redirected appdata folders launch code with appdata redirected to a unc path or can launch 'code --user-data-dir servershare$code' error Unable to write program user data , code trying to write to c:share$ Users do not have access to write to c: grant full control to root of C: and launch code a new folder is created c:share$ file created c:share$codeUserglobalStorage is created and code launches does not use the unc path while all other files are written to servershare$code fine with version 1.79.2
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.81.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
based on the above steps looks like the sqlite database is not using the unc path, passing the issue to you.
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
Same issue. installed 1.82.0-insider build. Still creates the in the wrong location.
excellent finding! I think this is a regression from partitioning state per profile. Specifically: When using , UNC paths only work for scheme but now I think we have as scheme. I am not sure when we made that flip.

I think this is spreading to a lot more places, the code is very old and was always assuming scheme to be used, which will not work anymore if a UNC path is used: I think we will have to make a pass over usage and find those that potentially use a non-file scheme...
I think I start to understand the issue better, it seems quite specific to global storage only, the other in the seem to be mainly of scheme. I believe this started with moving out of the environment service and into the profile service:
The change to scheme started happening from this change - - I started using this scheme for all user data to adopt atomic write. Since I had reverted atomic write for user data in this commit - - I can revert to use file scheme for user data on main. But going forward, I will bring back user data scheme and probably we should our file service and uri identitiy utilities instead of using fspath and path join.
but there is a point where our file service is no longer in charge: when we hand of a to SQLite3 module, we really have to give it a proper path that is a UNC path if the user picked a UNC location. So just using will not help here, we need to find a way that is not breaking UNC paths in all places where we need it.
Thats right, I also observed that we browsing the storage code. May be we should convert this back to file scheme before using in those places?
yes, doing seems right to me, even though ugly. Curious: with your custom file system provider on , are you converting back to a URI and then handing the off to the disk file system provider? Or do you convert one level above on the level of the file service? Asking, because I wonder if there is already a bug in your provider where we potentially loose UNC paths.
Thinking a bit more about this, I wonder if should statically allow us to register a scheme to behave like a scheme. Because, we do take an existing well defined of scheme and turn that into . This in turn means, every client that deals with such a would need to ensure that the scheme is converted back to before using the . That seems fragile. If we could tell to treat like a scheme, maybe the change would be easier and less fragile?
IMO this is as ugly as using on URI, because it can cause issues anytime.

Even if you know the scheme of the URI converting to file scheme is always safe. Here is the conversion logic: This is handled in the FSP of vscode-userdata. I just change the scheme and pass it to the native FSP.