Linux user data directory

VSCode — what exactly —user-data-dir is specifiying

What exactly is —user-data-dir specifiying? From —help parameter: —user-data-dir

Specifies the directory that user data is kept in. Can be used to open multiple distinct instances of Code. Is it storing some temporary files there? Is it about the access path to config files? I am asking as I want to run VSCode (or Codium to be more exact) with sudo (I want to edit system config file that is read restricted) which requires this parameter for reasons unclear to me.

I think for «mortal» user, it would default to: ~/.vscode , as «root» you’d have to specify it accordingly . see also

VSC saves some stuff for each Workspace/Folder it has opened, it also needs a place to store the extensions you have installed (maybe a different directory argument)

2 Answers 2

_{Since sudo -ing VS Code at command-line launch is only a thing on Linux, this question assumes you’re on Linux, and restricts its context to Linux.}

TL;DR

To answer your question directly: the user-data-dir parameter points to a folder where all personalisation except extensions resides — unique to each user.

Why does sudo -ing Code need —user-data-dir ?

In typical installations of either OS and VS Code, this folder owned by the regular user cannot be accessed by the superuser.

Hence a VS Code session running with effective UID=0 tries but fails to write to the invoking user’s (not the superuser’s) config folder. This is what the error message prevents from happening, by forcing the user to provide an explicit root -accessible folder.

Detailed Explanation

There are two main folders that VS Code uses to store configuration data:

1. An extensions folder (self explanatory) — contained in ~/.vscode [1]
2. user-data-dir ; a folder for all other personalisable things (settings, keybindings, GitHub/MS account credential caches, themes, tasks.json , you name it) [2]

On Linux the latter is located in ~/.config/Code , and has file permissions mode 0700 (unreadable and unwritable by anybody other than the owner).

This causes issues, as VS Code tries and fails to access said directory. The logical solution is to either modify the permissions (recursively) of ~/.config/Code to allow root access, or — arguably saner and objectively more privacy-respecting — to use a separate directory altogether for the sudo ‘ed VS Code to access.

The latter strategy is what the community decided to adopt at large; this commit from 2016 started making it compulsory to pass an explicit —user-data-dir when sudo -ing VS Code on Linux.

Should You be Doing This in the First Place?

Probably not! If your goal is to modify system config files, then you could stick to an un-elevated instance of Code, which would prompt you to Save as Admin. when you try to save. See this answer on Ask Ubuntu on why you probably want to avoid elevating VS Code without reason (unless you understand the risks and/or have to), and this one on the same thread on what you could do instead.
However, if the concerned file is read-restricted to root as well, as in the O.P’s case, then you hardly have a choice 😕; sudo away! 😀

_{[1] & [2]: If you want to know more about the above two folder paths on different OSes, see [1] and [2]}

Источник

User Data Directory

The user data directory contains profile data such as history, bookmarks, and cookies, as well as other per-installation local state.

Each profile is a subdirectory (often Default ) within the user data directory.

Current Location

To determine the user data directory for a running Chrome instance:

1. Navigate to chrome://version
2. Look for the Profile Path field. This gives the path to the profile directory.
3. The user data directory is the parent of the profile directory.

• [Profile Path] C:\Users\Alice\AppData\Local\Google\Chrome\User Data\Default
• [User Data Dir] C:\Users\Alice\AppData\Local\Google\Chrome\User Data

Default Location

The default location of the user data directory is computed by chrome::GetDefaultUserDataDirectory .

• OS platform,
• branding (Chrome vs. Chromium, based on is_chrome_branded in GN args), and
• release channel (stable / beta / dev / canary).

Windows

The default location is in the local app data folder:

• [Chrome] %LOCALAPPDATA%\Google\Chrome\User Data
• [Chrome Canary] %LOCALAPPDATA%\Google\Chrome SxS\User Data
• [Chromium] %LOCALAPPDATA%\Chromium\User Data

(The canary channel suffix is determined using InstallConstants::install_suffix .)

Mac OS X

The default location is in the Application Support folder:

• [Chrome] ~/Library/Application Support/Google/Chrome
• [Chrome Canary] ~/Library/Application Support/Google/Chrome Canary
• [Chromium] ~/Library/Application Support/Chromium

(The canary channel suffix is determined using the CrProductDirName key in the browser app’s Info.plist .)

Linux

The default location is in ~/.config :

• [Chrome Stable] ~/.config/google-chrome
• [Chrome Beta] ~/.config/google-chrome-beta
• [Chrome Dev] ~/.config/google-chrome-unstable
• [Chromium] ~/.config/chromium

(The beta and dev channel suffixes are determined from $CHROME_VERSION_EXTRA , which is passed by the launch wrapper script.)

The ~/.config portion of the default location can be overridden by $CHROME_CONFIG_HOME (since M61) or by $XDG_CONFIG_HOME .

Note that $XDG_CONFIG_HOME affects all applications conforming to the XDG Base Directory Spec, while $CHROME_CONFIG_HOME is specific to Chrome and Chromium.

Chrome OS

The default location is: /home/chronos

Android

The default location comes from Context.getDir and is specific to the app.

iOS

The default location is inside the application support directory in the app sandbox.

• [Chrome] Library/Application Support/Google/Chrome
• [Chromium] Library/Application Support/Chromium

Overriding the User Data Directory

Command Line

On all platforms, the user data directory can be overridden by passing the —user-data-dir command-line flag to the Chrome binary.

Environment (Linux)

On Linux, the user data directory can also be overridden with the $CHROME_USER_DATA_DIR environment variable.

The —user-data-dir flag takes precedence if both are present.

Chrome Remote Desktop sessions (Linux)

A single Chrome instance cannot show windows on multiple X displays, and two running Chrome instances cannot share the same user data directory. Therefore, it’s desirable for Chrome to have a separate user data directory when running inside a Chrome Remote Desktop (CRD) virtual session on a Linux host.

By default, CRD achieves this by setting $CHROME_USER_DATA_DIR in the session. Unfortunately this means that inside the session we don’t get separate defaults for different channels (Stable, Beta, Dev) or for Chrome vs. Chromium. This can lead to profile version errors (“Your profile can not be used because it is from a newer version of Google Chrome”).

Since M61, this can be solved by setting $CHROME_CONFIG_HOME instead of $CHROME_USER_DATA_DIR . Specifically, put the following in ~/.chrome-remote-desktop-session :

export CHROME_CONFIG_HOME="$HOME/.config/chrome-remote-desktop/chrome-config" unset CHROME_USER_DATA_DIR . /etc/chrome-remote-desktop-session

Then restart the host by running: /etc/init.d/chrome-remote-desktop restart

Writing an AppleScript wrapper (Mac OS X)

On Mac OS X, you can create an application that runs Chrome with a custom —user-data-dir :

set chrome to "\"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome\"" set userdatadir to "\"$HOME/Library/Application Support/Google/Chrome Alt\"" do shell script chrome & " --user-data-dir=" & userdatadir & " > /dev/null 2>&1 &"

1. Modify as needed for your installation path, Chrome versus Chromium, and desired user data directory.
2. Save the script in your Applications directory with the file format “Application”.
3. Close the Script Editor, find your newly created application, and run it. This opens a Chrome instance pointing to your new profile.

If you want, you can give this application the same icon as Chrome:

1. Select the Google Chrome application and choose File > Get Info.
2. Select the icon at the top left of the info dialog. You will see a blue highlight around the icon.
3. Press ⌘C to copy the icon.
4. Open the info dialog for the new application and select the icon in the top left.
5. Press ⌘V to paste the copied icon.

User Cache Directory

On Windows and ChromeOS, the user cache dir is the same as the profile dir. (The profile dir is inside the user data dir.)

On Mac OS X and iOS, the user cache dir is derived from the profile dir as follows:

1. If Library/Application Support is an ancestor of the profile dir, the user cache dir is Library/Caches plus the relative path from Application Support to the profile dir.
2. Otherwise, the user cache dir is the same as the profile dir.

• [user data dir] ~/Library/Application Support/Google/Chrome
• [profile dir] ~/Library/Application Support/Google/Chrome/Default
• [user cache dir] ~/Library/Caches/Google/Chrome/Default

On Linux, the user cache dir is derived from the profile dir as follows:

1. Determine the system config dir. This is ~/.config , unless overridden by $XDG_CONFIG_HOME . (This step ignores $CHROME_CONFIG_HOME .)
2. Determine the system cache dir. This is ~/.cache , unless overridden by $XDG_CACHE_HOME .
3. If the system config dir is an ancestor of the profile dir, the user cache dir is the system cache dir plus the relative path from the system config dir to the profile dir.
4. Otherwise, the user cache dir is the same as the profile dir.

• [user data dir] ~/.config/google-chrome
• [profile dir] ~/.config/google-chrome/Default
• [user cache dir] ~/.cache/google-chrome/Default

On Android, the user cache directory comes from Context.getCacheDir.

Источник