New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atom should use standard directories correctly on Linux and Windows #8281

Open
sergey-shambir opened this Issue Aug 8, 2015 · 44 comments

Comments

Projects
None yet
@sergey-shambir

sergey-shambir commented Aug 8, 2015

(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 comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 8, 2015

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

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

ghost commented Aug 8, 2015

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

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

@50Wliu

This comment has been minimized.

Show comment
Hide comment
@50Wliu

50Wliu Aug 8, 2015

Member

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

Member

50Wliu commented Aug 8, 2015

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

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Aug 9, 2015

Contributor

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 😢

Contributor

envygeeks commented Aug 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mwilliammyers

mwilliammyers Aug 9, 2015

👍

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.

mwilliammyers commented Aug 9, 2015

👍

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

This comment has been minimized.

Show comment
Hide comment
@jamen

jamen Aug 13, 2015

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.

jamen commented Aug 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@kovbal

kovbal Aug 13, 2015

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.

kovbal commented Aug 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@pedromaltez

pedromaltez Oct 6, 2015

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.

pedromaltez commented Oct 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@apjanke

apjanke Oct 16, 2015

+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.

apjanke commented Oct 16, 2015

+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.

@isiahmeadows

This comment has been minimized.

Show comment
Hide comment
@isiahmeadows

isiahmeadows Nov 8, 2015

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.

isiahmeadows commented Nov 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@sagebind

sagebind Nov 30, 2015

👍 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.

sagebind commented Nov 30, 2015

👍 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.

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Nov 30, 2015

Contributor

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.

Contributor

paulcbetts commented Nov 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jamen

jamen Nov 30, 2015

@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.

jamen commented Nov 30, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@apjanke

apjanke Nov 30, 2015

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.

apjanke commented Nov 30, 2015

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.

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Nov 30, 2015

Contributor

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!")

Contributor

paulcbetts commented Nov 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Nov 30, 2015

Contributor

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.

Contributor

envygeeks commented Nov 30, 2015

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.

@paulcbetts

This comment has been minimized.

Show comment
Hide comment
@paulcbetts

paulcbetts Nov 30, 2015

Contributor

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.

Contributor

paulcbetts commented Nov 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Nov 30, 2015

Contributor

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.

Contributor

envygeeks commented Nov 30, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jschneider

jschneider Nov 30, 2015

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
  1. 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
  1. 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)
  1. 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
  1. Step - final migration (several months later)
  • The user will be notified every day that the migration should be done now.

jschneider commented Nov 30, 2015

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
  1. 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
  1. 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)
  1. 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
  1. Step - final migration (several months later)
  • The user will be notified every day that the migration should be done now.
@jamen

This comment has been minimized.

Show comment
Hide comment
@jamen

jamen Nov 30, 2015

+1 for @jschneider's steps.

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

jamen commented Nov 30, 2015

+1 for @jschneider's steps.

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

@severen

This comment has been minimized.

Show comment
Hide comment
@severen

severen Dec 1, 2015

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.

severen commented Dec 1, 2015

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.

@skmlcd

This comment has been minimized.

Show comment
Hide comment
@skmlcd

skmlcd Feb 29, 2016

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

skmlcd commented Feb 29, 2016

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

@Siilwyn

This comment has been minimized.

Show comment
Hide comment
@Siilwyn

Siilwyn Feb 29, 2016

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.

Siilwyn commented Feb 29, 2016

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.

@isiahmeadows

This comment has been minimized.

Show comment
Hide comment
@isiahmeadows

isiahmeadows Feb 29, 2016

@Siilwyn

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

isiahmeadows commented Feb 29, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Siilwyn

Siilwyn Feb 29, 2016

@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.

Siilwyn commented Feb 29, 2016

@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.

@MicahZoltu

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Mar 12, 2016

I would like to emphasize comment from @apjanke #8281 (comment). The original description here (and many comments) reference *:\Users\%USERNAME%\AppData. For all of the reasons mentioned in his post, an application should not reference those paths directly! This will break on some international installs, it will break on some domain installs, it will break on users simply redirecting various folders to other drives.

Because there are so many comments here, it would be nice if the original description could be updated to reflect this. I don't believe anyone participating in this discussion has a problem with this particular change. It sounds like most of the debate is about whether to make a change at all.

MicahZoltu commented Mar 12, 2016

I would like to emphasize comment from @apjanke #8281 (comment). The original description here (and many comments) reference *:\Users\%USERNAME%\AppData. For all of the reasons mentioned in his post, an application should not reference those paths directly! This will break on some international installs, it will break on some domain installs, it will break on users simply redirecting various folders to other drives.

Because there are so many comments here, it would be nice if the original description could be updated to reflect this. I don't believe anyone participating in this discussion has a problem with this particular change. It sounds like most of the debate is about whether to make a change at all.

@silasdavis

This comment has been minimized.

Show comment
Hide comment
@silasdavis

silasdavis Apr 19, 2016

Why is my ~/.atom directory 500 MB?
-- Disgusted, of Tunbridge Wells

As others have said, it would be nice to have an clear single point of backup to preserve any declarative atom config from which we can rebuild a working installation. Would make sense to follow existing standards all things being equal, and it looks like people have solved the migration/backwards compatibility problem on paper at least.

silasdavis commented Apr 19, 2016

Why is my ~/.atom directory 500 MB?
-- Disgusted, of Tunbridge Wells

As others have said, it would be nice to have an clear single point of backup to preserve any declarative atom config from which we can rebuild a working installation. Would make sense to follow existing standards all things being equal, and it looks like people have solved the migration/backwards compatibility problem on paper at least.

@caesar

This comment has been minimized.

Show comment
Hide comment
@caesar

caesar May 29, 2016

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.)

caesar commented May 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Siilwyn

Siilwyn Sep 2, 2016

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

Siilwyn commented Sep 2, 2016

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

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Sep 2, 2016

Contributor

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

Contributor

envygeeks commented Sep 2, 2016

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

@Siilwyn

This comment has been minimized.

Show comment
Hide comment
@Siilwyn

Siilwyn Sep 2, 2016

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

Siilwyn commented Sep 2, 2016

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

@smyrman

This comment has been minimized.

Show comment
Hide comment
@smyrman

smyrman Dec 1, 2016

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.

smyrman commented Dec 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@swirly

swirly Feb 17, 2017

+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.

swirly commented Feb 17, 2017

+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.

@stale

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Feb 17, 2018

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. Because the Atom team treats their issues as their backlog, stale issues are closed. If you would like this issue to remain open:

  1. Verify that you can still reproduce the issue in the latest version of Atom
  2. Comment that the issue is still reproducible and include:
    • What version of Atom you reproduced the issue on
    • What OS and version you reproduced the issue on
    • What steps you followed to reproduce the issue

Issues that are labeled as triaged will not be automatically marked as stale.

stale bot commented Feb 17, 2018

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. Because the Atom team treats their issues as their backlog, stale issues are closed. If you would like this issue to remain open:

  1. Verify that you can still reproduce the issue in the latest version of Atom
  2. Comment that the issue is still reproducible and include:
    • What version of Atom you reproduced the issue on
    • What OS and version you reproduced the issue on
    • What steps you followed to reproduce the issue

Issues that are labeled as triaged will not be automatically marked as stale.

@stale stale bot added the stale label Feb 17, 2018

@Siilwyn

This comment has been minimized.

Show comment
Hide comment
@Siilwyn

Siilwyn Feb 17, 2018

Issue is still relevant.

Siilwyn commented Feb 17, 2018

Issue is still relevant.

@the-j0k3r

This comment was marked as spam.

Show comment
Hide comment
@the-j0k3r

the-j0k3r Jun 27, 2018

This issue has been automatically marked as stale because it has not had recent activity.

mmm this bot is not happy unless there's blood? JK ;) lets bump this for the sake of sakes.

the-j0k3r commented Jun 27, 2018

This issue has been automatically marked as stale because it has not had recent activity.

mmm this bot is not happy unless there's blood? JK ;) lets bump this for the sake of sakes.

@Seb-dev

This comment has been minimized.

Show comment
Hide comment
@Seb-dev

Seb-dev Aug 9, 2018

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

Seb-dev commented Aug 9, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment