Atom should use standard directories correctly on Linux and Windows

[sergey-shambir]

(updated 14 aug 2015)

On Linux

XDG Base Directory Specification defines standard paths inside $HOME folders that should be used by applications. Unfortunately, Atom creates directory "/.atom" and puts part of data into it. Another part correctly placed at "/.config/atom". Directory "~/.cache/atom" created, but seems to stay unused.

• Atom should not either create "~/.atom" or use it
• Atom should use "~/.config/atom" for all configuration files
• Atom should use "~/.local/share/atom" for all intermediate data and downloaded packages
• Atom should use "~/.cache/atom" for all cache and intermediate data that can be deleted without breaking user's work
• Lowercase version of application name used in paths - "atom" instead of "Atom"

On Windows

Atom creates .atom directory in user's home folder - it's absolutely wrong behaviour since most Windows apps don't and shouldn't create anything in user folder.

• Atom should not either create "C:\Users%USERNAME%.atom" or use it
• Atom should use "C:\Users%USERNAME%\AppData\Roaming\Atom" for all configuration files; Roaming used to allow standard way of synchronization between user's devices
• Atom should use "C:\Users%USERNAME%\AppData\Local\Atom" for all intermediate data and downloaded packages
• Atom should use "C:\Users%USERNAME%\AppData\Local\Atom\cache" for all cache and intermediate data that can be deleted without breaking user's work
  Note that Windows can be installed on drive "D:", so "C:\Users" used as example.

More information on standard paths

For more information see tables for Windows and Linux at http://doc.qt.io/qt-5/qstandardpaths.html
You can search at this page by words:

• DataLocation
• CacheLocation
• ConfigLocation

[ghost]

This is a duplicate of #7701, but much more informed, and extended to windows.

(On linux I’d also suggest using lowercase.)

[50Wliu]

See also #2199 (Linux) and #6346 (Windows).

[envygeeks]

Please no uppercase names on Linux, even Google adheres to that want. ~/.config/atom maybe I'm the only one who gets annoyed (especially at GNOME who uses /etc/NetworkManager) but yeah 😢

[mwilliammyers]

👍

But just to be clear, per the XDG base directory spec, it should not be ~/.config/atom but $XDG_CONFIG_HOME/atom and not ~/.cache/atom but $XDG_CACHE_HOME/atom etc. allowing the user to specify those directories themselves (the whole point of the XDG system). ~/.config, ~/.local/share and ~/.cache are simply the defaults... so atom should only use ~/.config as a default if $XDG_CONFIG_HOME is not set.

Also could atom respect those paths on OS X if $XDG_CONFIG_HOME etc. are set too instead of creating ~/.atom... Either that or follow OS X path specs such as ~/Library/Application\ Support/atom etc.

[jamen]

I agree, but like the others have said: use lowercase on Linux ~/.config/atom. That's pretty much what all the others folders in there follow. I'm not sure about Windows, but I imagine it's the same scenario. So in general, I think the folder should be lowercase.

[kovbal]

On Windows Atom should use C:\Users\%USERNAME%\AppData\Roaming instead of C:\Users\%USERNAME%\AppData\Local for configuration files, since the those should be synced across workstations in case of a roaming user profile.

[pedromaltez]

I had already prepared the issue report below for atom/apm when I thought to look in atom/atom for issues mentioning XDG_CONFIG_HOME.

It looks like a solution not adhering to the XDG specs was preferred in #5385, even though this problem had been mentioned quite a while before in #2199 and #2261. There seemed to be some reluctance to change it to the XDG form in those issues because of widespread adoption and not wanting to break users' configurations. Atom has now reached 'stability' at 1.0.0 so I can only imagine that that would exacerbate the issue but I'm hopeful this will get resolved.

I think this issue should concern itself with the locations of the files on all the supported platforms (linux/freebsd/os x/windows from what I can tell). I assume FreeBSD would follow the same standard as linux and just use XDG specs, although perhaps there's some specific standard for FreeBSD. There is a proper place that Apple defines as the place where applications should place their configuration files, and perhaps that should be the default on os x if neither $ATOM_HOME nor $XDG_CONFIG_HOME is specified. I don't know what the solution should be but we ought to keep on mind that Atom is an application that's used by hackery types/people that use the command line and they will probably expect to find the config files for this type of application somewhere in their $HOME directory or if they have set it, in the $XDG_CONFIG_HOME. My personal preference is certainly to follow the XDG spec if the variables are set.

I know I'm referring to atom/apm, but it's still relevant, as that would have to change if atom/atom changes. I'm specifically concerned with linux and os x systems below, as those are the systems I use and understand.

Respect XDG Base Directory Specification

It would be nice if atom followed the XDG Base Directory Specification. This, among other things, allows a user to specify a directory in which they want all applications to look for their user configurable setting files. Instead of having to set it individually for each application (like setting $ATOM_HOME) where it's even possible to do so (since plenty of applications have the locations hard coded), or having the config files live directly under $HOME, you can set the $XDG_CONFIG_HOME environment variable and let all applications look for their files in there, preferably in their own directory. A change like this shouldn't impact any user that doesn't have $XDG_CONFIG_HOME currently set, and it would, I assume, be a welcome change to any that does.

This is a small example of what not following the XDG Base Directory Specification and using your own application specific variables instead can end up causing, for some people:

# Vim
export VIMRC=$XDG_CONFIG_HOME/vim/vimrc
export VIM_CONFIG_DIR=$XDG_CONFIG_HOME/vim/config.d
export VIMINIT="source $VIMRC"
export VIM_CACHE=$XDG_CACHE_HOME/vim/vim

# Ruby tools
export IRBRC=$XDG_CONFIG_HOME/irb/irbrc
export PRYRC=$XDG_CONFIG_HOME/pry/pryrc

# Ruby versions below 2.1.0 are not aware of the GEM_SPEC_CACHE variable and
# will always place their gem cache in $HOME/.gem instead
export GEM_SPEC_CACHE=$XDG_CACHE_HOME/ruby/gem/spec

# Bundle config locations
export BUNDLE_CONFIG=$XDG_CONFIG_HOME/bundler/config

I've looked around and think that src/apm.coffee is the only file in the source (excluding tests) where anything would have to change.

I'm not particularly well versed in CoffeeScript and certainly don't really know its idioms, but this is fairly simple so I think instead of

getAtomDirectory: ->
  process.env.ATOM_HOME ? path.join(@getHomeDirectory(), '.atom')

it could be something along the lines of (this particular implementation feels kind of gross though... and I'm not even sure it works. Perhaps it's best to use if ... else instead of ? here?)

getAtomDirectory: ->
  process.env.ATOM_HOME ?
  ( process.env.XDG_CONFIG_HOME ? path.join(process.env.XDG_CONFIG_HOME, 'atom') path.join(@getHomeDirectory(), '.atom') )

or whatever this is in idiomatic CoffeeScript

getAtomDirectory: function() {
  if process.env.ATOM_HOME {
    return process.env.ATOM_HOME
  } else if process.env.XDG_CONFIG_HOME {
    return path.join(process.env.XDG_CONFIG_HOME, 'atom')
  } else {
    return path.join(@getHomeDirectory(), '.atom')
  }
}

such that the order in which atom and friends would look for the config files is: $ATOM_HOME -> $XDG_CONFIG_HOME/atom -> .config/atom (didn't implement this in the examples above though) -> $HOME/.atom This would cause the least amount of disruption, yet still kind of follows the XDG standard by falling back to a default of .config/atom. In an ideal world the original location and environment variable would be dropped, but keeping those would prevent people's configs from breaking. Only those that have already set $XDG_CONFIG_HOME are affected, as well as those that place their config file in the XDG default location. Similar things could be done for the cache/runtime directories. I'm just primarily concerned with the configuration files here for simplicity.

I understand this would likely also require changes in some tests and it would probably be a good idea to ensure consistency across atom/apm and atom/atom, as well as any other projects that make use of $ATOM_HOME.

I also understand that this can only really be seen as pretty low priority and I don't know if this is something that the maintainers would like to include or not. Still, from my perspective it would be nice to have. I'll look into it some more if I get a go ahead. Otherwise the alternative is just to set one more environment variable with export ATOM_HOME=$XDG_CONFIG_HOME/atom, which at the end of the day isn't that big of a deal.

Please let me know whether this might be a welcome change and I'll look into it further if so.

As mentioned by someone else on this thread, it's not a good idea to hard code the locations to ~/.config/atom, ~/.cache/atom, etc.

[apjanke]

+1 to this, especially on the Windows side. I think that would make it friendlier for advanced Windows users and administrators, who would know their platform's conventions, and use tools that make use of them.

Atom should use "C:\Users%USERNAME%\AppData\Roaming\Atom"
...
Note that Windows can be installed on drive "D:", so "C:\Users" used as example.

It's not just the drive letter that could be different; all these special "shell folders" are subject to renaming or relocation, due to localization, name conflicts, configuration by sysadmins, or changes between Windows versions. (For example, if multiple users with the same unqualified name log in to a machine (because they're from different domains, or the user names have changed), the profile folder basename will not match %USERNAME%.) They should be located using environment variables or corresponding Windows API calls, to respect this relocation.

The C:\Users\%USERNAME% folder is %USERPROFILE%.
The C:\Users\%USERNAME%\AppData\Roaming folder is %APPDATA%.
The C:\Users\%USERNAME%\AppData\Local folder is %LOCALAPPDATA%.

It's also a convention on Windows to add a "vendor" layer to the folder structure (for example, %APPDATA%\GitHub\Atom instead of %APPDATA%\Atom) to reduce the chance of product name collisions (and maybe to help in identifying what program created it). You might want to, or even need to, do that here: My %APPDATA% folder already has an %APPDATA%\Atom subdirectory that was there a few months prior to installing this Atom, and doesn't appear related. I don't know what it's from.

[dead-claudia]

For actual config being relocated on Linux, that could be a little inconvenient. +1 for the rest. Following file conventions is almost always a good thing.

Although I normally use Linux, I do feel that in Windows, not including the drive letter is better. It's better to use %AppData% than C:\Users\%Username%\AppData\Roaming, for example. Also, typically, %AppData% is used for config and saved settings, while %LocalAppData% is usually used for caching. I used to be a Windows power user, and that's what I have seen, but feel free to correct me if I'm wrong on any of this.

[sagebind]

👍 Yes please. The non-standard locations used by Atom make setting up my configuration files more work for me, since I have to selectively choose which individual files that are actually configuration I want to back up, instead of just using the whole ~/.config/atom directory like every other program I use on Linux.

[anaisbetts]

Copy-pasted from the other bug:

I'm pretty 👎 on this change:

• All of the documentation / 3rd party blogs point to C:\Users\NAME\.atom, this will lead to a ton of "I don't have a C:\Users\NAME\.atom folder!" questions because they followed some guide that hasn't been updated. Furthermore, we're now suggesting to put the files in a highly OS-dependent folder, making guides that only care about one platform (probably OS X) unusable for others.
• %AppData%\Atom (and ~/.config/atom on Linux) already has lots of stuff in it because it's the folder where Electron puts its data, whereas we expect users to directly edit files in this folder like styles.less. Mixing files that users should not at all edit and files they are expected to edit is Not Very Great.

In exchange for these pretty significant drawbacks, we don't really get anything in return, other than some "cleanliness". If Atom weren't already released software it'd be a different story, but this really will cause problems for users if we try to move the folder.

[jamen]

@paulcbetts: The XDG standard defaults to some of the things Atom is currently using anyways. Someone probably isn't using the XDG environment vars if they don't know what they are. And on the topic of support, the person needing help can simply state their operating system, and if they haven't used the XDG vars, it's in the location expected. On the topic of old references like blog posts and documentation, we should always be making Atom better, we shouldn't let 3rd parties hold us back. Blog posts can be edited.

As far as Electron using ~/.config/Atom, I would say that's a issue with Electron, so that would be another thing we should fix.

[apjanke]

The "third-party documentation" problem will solve itself. If this change is made, "where's my .atom folder?" will bubble up to the top of the Google & SO results pretty quickly, and new pages will replace the old. Users will get the info they need, and if they want to dig deeper, learn more about platform conventions for storing user data. And there will be an opportunity for new people to earn rep and googlejuice by writing about and cogently explaining this change.

"We can't change our mind about this design choice because some other people wrote about it" is ridiculous.

[anaisbetts]

The XDG standard defaults to some of the things Atom is currently using anyways. Someone probably isn't using the XDG environment vars if they don't know what they are

Not correctly looking up XDG folder names is different, I'm 👍 on fixing any of those kinds of bugs

"We can't change our mind about this design choice because some other people wrote about it" is ridiculous.

Not only is it not ridiculous, it's the major reason that Linux as a platform is continuing to fail - this blind desire to break software and the ecosystems around it in order to promote something that's more "technically correct". In this case, there's not even a user benefit! There is solely cost. Not a single user's life will be better as a result of this change. Not one. However, many users will be confounded and frustrated by it. Developers making choices like this have consistently hamstrung OSS platforms, over and over again.

I appreciate @pedromaltez's approach in that he's thinking about the end user and the disruption this could cause, but even his approach has problems, in that it is now difficult to tell an arbitrary user where their Atom directory is ("Well, it's here, unless it's here, it might also be there uhhhhh, it depends!")

[envygeeks]

Not only is it not ridiculous, it's the major reason that Linux as a platform is continuing to fail - this blind desire to break software and the ecosystems around it in order to promote something that's more "technically correct".

That's how you do it, blame Linux because you're bad at computers. Linux has been the same, you chose not to follow those principles (and you even demonstrated the lack of care for any principles on Windows too, are you going to say that's the reason that Windows the biggest operating system on the plant doesn't gain traction?)

Tell that to servers that run the site you are using to talk bad about Linux, or this user who knows thousands of people who use Linux. Or the hundreds of thousands of people (actually more like millions) who use Ubuntu.

[anaisbetts]

Tell that to servers that run the site you are using to talk bad about Linux

I feel as if you think I want Linux or OSS to fail, which can't be further from the truth. On the contrary, I thoroughly want open-source software to succeed, which is why we cannot break user software unless we absolutely must.

Do you know why Windows is the most popular operating system on the planet? It's not because its architecture is particularly good or elegant or beautiful (I've seen the source, I assure you, it's not). Why did something that's worse become popular?

Here's one big reason: because when you get an app, and it says on the box "Runs on Windows", you don't even have to think about what version it was written for. It Just Works. Entire buildings full of people put in thousands of man-hours into making sure when you download that EXE file, even if it's from 1998 and was never "written correctly" and didn't follow the "principles", it just works.

So, Atom should Just Work, and when we kick out the user's config dir out from under them, or make breaking changes to make an API "better", or or or, Atom no longer Just Works.

[envygeeks]

which is why we cannot break user software unless we absolutely must.

You don't need to break users software, you need to add utilities like Postfix where you can get information about the system and where everything is and ask users to post that, Docker does that too, even our software does that regardless of platform, because things are configurable and they can type "atom [--]info" and suddenly you have all the information you need.

Here's one big reason: because when you get an app, and it says on the box "Runs on Windows", you don't even have to think about what version it was written for. It Just Works. Entire buildings full of people put in thousands of man-hours into making sure when you download that EXE file, even if it's from 1998 and was never "written correctly" and didn't follow the "principles", it just works.

Except they don't put that much effort in, and no, you cannot run a lot of binaries from 1998 on Windows, trust me, I've tried before just for fun and also, a lot of XP apps required a dedicated virtual machine, remember that Windows XP mode? That was because those thousand of hours of man-time were wasted and compatibility mode really turned out to not be all that good (and still isn't all that good, though it's improved.) So they needed a virtual machine to power those apps.

[jschneider]

Guys, please try to calm down a bit.

I think there are a few things, that seem to be clear:

• the current location of config files is not the best choice
• following XDG specs on Linux is preferable
• using AppData\Roaming directories on Windows is preferable
• just changing the config directories and leaving the user without his configuration is a very, very bad idea

Therefore it seems to be pretty obvious that we need:

• a nice migration path for all users
• a (long) time where the old directories can still be used

Maybe this could be solved like this:

1. Step - Preparation / early adopters:

• The new directories are used if they exist. If they do not exist, atom uses the old directories.
• Atom uses still the old directories per default (for easy use for new users)
• There is a menu entry (help menu?) that opens the config directory
• The new directories are documented

2. Step - Manual migration possible

• Atom adds a "migration wizard" to the menu. This wizard
  • moves the content of the old directories to the new locations.
  • adds a readme file into the old folder containing the location of the new folder
  • and/or creates a symlink to the new location
• is still using the old directory as default

3. Step - Changing default

• Atom uses the new directories by default
• Users are notified (maybe once a month) that the configuration files should be migrated (see above)

4. Step - enforcing the new directories

• If everything above works fine, the user could be notified maybe once a month that the configuration files should be migrated (see "migration wizard").
• The frequency of notifications is increased

5. Step - final migration (several months later)

• The user will be notified every day that the migration should be done now.

[jamen]

+1 for @jschneider's steps.

We're not "breaking the software" if we choose to do this correctly, and migrate appropriately.

[severen]

Not a single user's life will be better as a result of this change. Not one.

I disagree, separating configuration, cache and data out into separate directories makes backups of user configuration a whole lot easier (just a tar -zcf config.tar.gz .config away ) plus allowing all cached data to be blown away with a simple rm -r ~/.cache.

Also, +1 to @jschneider's steps which seem like a pretty solid solution.

[ghost]

👍 on this issue, especially on Linux. Any progress?

[Siilwyn]

As @Dremora commented at a related issue in Februari 2015! The changes can be made backward-compatible and it doesn't even have to be complicated. I mean even a bunch of symlinks could solve a lot. Another choice/option could be to slowly migrate as @jschneider proposed which may even be a better option.

Either way, just ditching this of as "we already released Atom so we can't change it" seems stupid and holds back improvement.

[dead-claudia]

@Siilwyn

Yes, symlinks are backwards compatible enough to be semver minor (unless people are using lstat), but removing it is a semver major break.

[Siilwyn]

@isiahmeadows I only listed symlinks as a possible solution that could be combined with @jschneider's proposal. Though I think falling back to the old configuration location like @Dremora suggested is a bit cleaner. That said, plenty of options to do this in a graceful way.

[caesar]

Is this going to be fixed? I'm getting really frustrated with all this junk in my home directory. Modern apps should be storing their data in the standard locations. Its not difficult.

(By the way, maybe the title should be updated as this is not specific to Linux and Windows.)

[Siilwyn]

Greenkeeper moved forward by moving the old config to the new location if it exists: greenkeeperio/rc#3 (comment)

[envygeeks]

I'm sorry, but... what's that to do with Atom again?

[Siilwyn]

It shows a possible solution the this issue which is in turn related to Atom.

[smyrman]

Thanks everyone for your feedback on this. While this is something that we may do for future major versions, we won't be considering this for v1.x.

Just in case anyone of the Atom developers wonders why it's a good idea to follow the XDG Base Directory standard, it's not all about being as correct as possible, but also about adding real value to the end-users.

The best use-case I got myself, would be to sync the atom config files between my macbook and my Linux desktop alongside other developer tool configs, e.g. git config and neovim config. While I do so, I really, really do not want to sync compiled cache or other downloaded content at the same time.

Following the XDG Base Directory spec as well as the correct conventions for MacOS and Windows, makes this sync significantly easier, as you could just do a git init in ~/.config and manually add the files/folders you want to sync. Today I need to have bash scripts that creates ugly symlinks, which works, but it's tedious to maintain :-(

Hopefully the initial backwards-compatibility will be straight forward. Even if I had to add an export ATOM_XDG_BASE_DIRECTORY_EXPERIMENT=1 to my shell's initfile, I would be quite happy with that as the initial support. Note that export ATOM_HOME="$XDG_CONFIG_HOME/atom" does not appear to be sufficient, as this adds non-config files and cache to the config directory.

[swirly]

+1 on a resolution of this bug.

As I explained in a discussion thread, I'm trying to deploy atom in a high school on a standard industrialized base. I think atom has a great potential and we begin to teach code massively here in France

we have 1300+ users, using 300+ computers

of course, we use roaming profiles, so the users usually get their apps configured the same way on ALL computers. Everybody just use two or three differents computers in a day, and may be 10 in a week !

The correct way to implement this is to use the

%APPDATA% environnement variable on windows, wich defaults to C:\Users%username%\Appdata\Roaming

This is the synchronised folder where the app should set their configuration (for those not using registry)

Each time one of our user change computers (all day long) he loose all the packages he downloaded and any config he made.

Even if he come backs three days laters on the same computer, the profile was erased (any profile older than 24hour is automatically erased, for saving disk space : 1300+ users...)

Actually, atom can not have any customisation other than the "out of the box" one. It's a real problem. for a highly customisable editor.

The usual environment variables for microsoft OS can be found here (for windows 7 and Vista)
https://technet.microsoft.com/en-us/library/dd560744(v=ws.10).aspx

It's very important to use %APPDATA% and not a hardcoded C:... as on some networks, %APPDATA% is modified by system administrator (for many many reasons) by GPO

hope it helps.

[Seb-dev]

Same problem with each release of atom-bin (1.29) for Gentoo
resolved with
chmod +x /usr/share/atom/resources/app.asar.unpacked/node_modules/dugite/git/bin/git

[sander1095]

BUMP because of recent discussion on Reddit

https://www.reddit.com/r/programming/comments/amp06h/dotfile_madness/
https://www.reddit.com/r/linux/comments/971m0z/im_tired_of_folders_littering_my_home_directory/

[lee-dohm]

Thanks for the feedback.

I understand that people have strong opinions on this. Realistically, this isn't something that the Atom team is going to take the time to work on anytime soon. We also won't be accepting a pull request for this functionality without an accepted RFC that seriously considers and addresses all of the ramifications of making such a change to existing users and users of all skill levels.

Thanks again for all the interest.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!