Change:
} function getNixIPCHandle(userDataPath: string, type: string): string { <ins> if (process.env['XDG_RUNTIME_DIR']) { return path.join(process.env['XDG_RUNTIME_DIR'], `${pkg.name}-${pkg.version}-${type}.sock`); } </ins> return path.join(userDataPath, `${pkg.version}-${type}.sock`); }

Discussion:
VSCode Version: 1.10.2 (code1.10.2-) OS Version: Ubuntu 16.04 LTS Steps to Reproduce: home directory w/ on AFS. . the following error: Code starts normally if moving the directory to a local filesystem and symlinking it in. I would reckon that it's probably not portable to put the kind of thing that is in the homedir, as it may very well be mounted in fun ways or on network filesystems. This behaviour is new since the previous release I ran, which I believe was .
Squinting at the it seems like sockets and other runtime files shall be created in , which on my system is down in .
Not sure what to do here. Best I can do is to recommend not using AFS. Does it support socket files?
I don't have any choice in AFS for my home directory where the default XDG config directory is located. Sure I could point the config elsewhere, but then I'd lose access to the same configuration across machines which is the whole point of a shared homedir. AFS doesn't support named pipes in the filesystem intentionally as it's a distributed filesystem and the semantics for how they would work across the world is hard to pin down. As far as I interpret the XDG specification, you should not use the config directory for runtime state. They explicitly mention the runtime dir for that. I don't know where in the stack this is done, but it's quite wrong to use the possibly shared homedir for machine-local state. supports things like 's named pipes
Got it, thanks.
the same thing for the socket files in /tmp/ like /tmp/vscode--a2f2-4ba7-8e8c- they should go in $XDGRUNTIMEDIR (if available, if not /tmp is ok). the benefit of $XDGRUNTIMEDIR is it goes away when the user logs out.
The same issue appears with sshfs mounted home directory
We were force to undo this change since it breaks many assumptions at startup, when this variable may or may not be set. Unfortunately, the correct workaround for these cases is to call code with .
Hi!

Now 1.17. stopped working on AFS Not sure if the workaround you gave makes sense, as the $XDGRUNTIMEDIR directory gets deleted every time the user restarts. I would be happy if you could fix that. Thanks!
Does the workaround work for you at all?
Thanks for the fast reply. It does work for one session, but settings for example get deleted when I reboot.
Why is that? I don't really know AFS.
Me neither, but what I think right now: The XDGRUNTIMEDIR variable gives something like on my machine, which apparently gets deleted when rebooting or the XDGRUNTIMEDIR changes. I can’t say right now as I am not at my computer. If you call code using your workaround, all user data gets stored in that directory and is inaccessible after reboot. But the problem ia not the user data, it is the .sock file that has trouble with AFS. So it is just this file that needs to be stored somewhere else in a non AFS directory.
Currently the files are within user data dir. So... in your system should they live somewhere else? ?
Yeah, for example. I don’t know what the .sock file does, but if it is not a problem that it is removed after reboot that might be an option. But isn’t that what the pull request did? Just storing the .sock file somewhere else...
Yes, did exactly that, but based on an env variable, which is very problematic in many cases. So, I propose to introduce a cli option to set the socket files location on Linux. So you'd need to launch it as: Would that work for you?
Cool, I would expect that to work for me. Thanks! Let me know if you want me to test.
problematic in what cases? the XDG recommendations are pretty clear and easy to follow. You have a DATA dir, CONFIG dir and RUNTIME dir. There are environment variables to specify the directories or there are defaults when the env vars are not there. What doesn't work in vscode with that setup?
Let's talk Linux only. It makes a big difference in terms of process environment if you open an application from within a shell or using a UI gesture. The shell usually has all you favourite environments, often set up in files or similar (think , ).

The process (usually some Gnome or KDE process) which spawns Code using the UI gesture doesn't have this environment because it never went through a shell, never really parsed and interpreted . So, users complain they can't use Node or Go within Code; the real problem is that Code's env doesn't match what their shell has. So: on startup, and only if Code wasn't launched in a shell, Code will the user's shell environment as best as it can. This is possibly a lengthy process (have you ever waited 1-2 seconds until you see that bash prompt?) so we can't have that as part of Code's critical startup sequence, otherwise we risk being slow to start as well. We do it in parallel while Code actually starts up and spawns a window. Eventually, when that env is know, it is promptly applied to all Code's processes. There's a race condition here. You see, we need to know the exact location of the IPC sockets at startup, before any window opens. If is (re)defined in the user's , we can't rely on it to compute the location of the sockets. We must know that value independently of the env loading code path. For the past few months we were relying on reading to determine the sockets paths. For some, this works well. For others, Code breaks in very unrelated ways: if is (re)defined in , there was a race condition between reading that value from and computing the sockets paths. It would often happen that the process which served the socket pointed one way while all other processes pointed the other way. We simply can't have that. One alternative for a fix is to ignore the value coming in from the user's . Do you think this would make sense?
XDGRUNTIMEDIR is typically set by pamsystemd, even before their Desktop Envrionment or login shell is started. If people redefine that in .bashrc (for interactive shells only) a lot of things will break for those shells. just an example of the sockets I have there (i.e. software that would break if I changed tne env var): So in conclusion I have not heard of anyone redefining XDGRUNTIME_DIR for interactive shells only, but if they do that, that's the users mistake to break things intentionally.

Alright, then let's do that: we'll simply ignore it when reading it after startup.