Created attachment 160305 [details] [review]
[ShellGlobal] Change config_dir to use XDG_CONFIG_HOME

While the extension system already uses that location, other
components use the deprecated $HOME/.gnome2 directory.
The existing data (app usage stats and looking glass history) is not
migrated to the new location.

Actually I'm a little uncertain whether XDG_CONFIG_HOME really is the correct location for the kind of data we store - possibly XDG_DATA_HOME would be more appropriate (especially for extensions).

Review of attachment 160305 [details] [review]:

There's certainly some confusion between config_home and data_home - but these two usages do seem more like Empathy logs or the Tracker database than some of the things that are put in ~/.config.

(Obviously if we switch to using data_home, the variable and property shouldn't be 'configdir')

Created attachment 160368 [details] [review]
[ShellGlobal] Change location for user files to XDG_DATA_HOME

While the extension system already uses an XDG location (XDG_CONFIG_HOME),
other components use the deprecated $HOME/.gnome2 directory.
The existing data (app usage stats and looking glass history) is not
migrated to the new location.

Not sure about the extensions - should those go to XDG_DATA_HOME as well?

Review of attachment 160368 [details] [review]:

Looks good to me. On extensions, thinks there isn't a right answer, but:

<owen> walters: You have an opinion on fmuellner's question of ~/.config/gnome-shell/extensions vs. ~/.local/share/gnome-shell/extensions ?
<walters> i would prefer the latter
<walters> but not strongly so
<drago01> yeah extensions aren't really "configuration"
<owen> walters: if we move them there, then we have the advantage of not having stuff in both places

Attachment 160368 [details] pushed as b1486f5 - [ShellGlobal] Change location for user files to XDG_DATA_HOME

The path for extensions has be updated to use XDG_DATA_HOME as well.

+  global->userdatadir = g_build_filename (g_get_user_data_dir (), "gnome-shell", NULL);
+  userdata_dir = g_file_new_for_path (global->userdatadir);
+  g_file_make_directory (userdata_dir, NULL, NULL);

This is doubly wrong. First, you need to use g_file_make_directory_with_parents() since you cannot guarantee the toplevel g_get_user_data_dir() dir already exists. Secondly, g_file_make_directory[_with_parents] creates the directories with permissions 0777, while the XDG standard mandates 0700 for the g_get_user_data_dir() part at least.

Created attachment 160400 [details] [review]
Fix userdata directory creation

When creating the directory to store user data, XDG_DATA_HOME is
not guaranteed to exist. Also, the standard mandates permissions
of 0700 for the directory.

Comment on attachment 160400 [details] [review]
Fix userdata directory creation

Looks good.

(I briefly wondered if we we should use 0700 for the parent and 0777 for the subdir but I can't think of any real advantage of that.)

(In reply to comment #8)
> (I briefly wondered if we we should use 0700 for the parent and 0777 for the
> subdir but I can't think of any real advantage of that.)

Mmmh, if access to the parent directory is denied, permissions of subsequent directories don't matter anyway, right?

Attachment 160400 [details] pushed as b09b306 - Fix userdata directory creation

(In reply to comment #9)
> (In reply to comment #8)
> > (I briefly wondered if we we should use 0700 for the parent and 0777 for the
> > subdir but I can't think of any real advantage of that.)
> 
> Mmmh, if access to the parent directory is denied, permissions of subsequent
> directories don't matter anyway, right?

Yes. 

Sometimes in similar situations you want the restrictive permissions only on the toplevel so that the user can easily change the overall permissions by changing just the toplevel. But I can't see it matters here.

*** Bug 598102 has been marked as a duplicate of this bug. ***