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

I've been working on fixing these and have pushed a branch here:
https://github.com/dieterv/glib/commits/windows

Review and feedback most welcome :)

(In reply to comment #0)
> Some of the user-specific directories currently returned by glib's utility
> functions often aren't the best choice:
> 
> g_get_user_cache_dir returns CSIDL_INTERNET_CACHE. To my knowledge, no program
> other than Internet Explorer uses this directory. A much better directory for
> this would be CSIDL_LOCAL_APPDATA, which is intended for storage of items
> specific to the user on current computer. Both Firefox and Opera store their
> cache in a subdirectory of CSIDL_LOCAL_APPDATA.

Fixed in the branch mentioned in comment #2

> g_get_user_data_dir and g_get_user_config_dir return CSIDL_LOCAL_APPDATA. As
> mentioned above, this directory is intended for user data specific to the
> current computer the program is running on - better choice would be
> CSIDL_APPDATA, which is intended for user data not specific to a computer (in a
> networked environment CSIDL_APPDATA can roam to other computers, which is
> useful when you want to have the same data/configuration synchronized
> automatically).

There is no distinction between local and roaming directories on all
other platforms where the XDG Base Directory specification is in effect.
It feels safer to follow the principle of least surprise and behave
the same on win32, leaving it up to application authors to make
an informed decision and call SHGetFolderPathW passing CSIDL_APPDATA
or SHGetKnownFolderPath passing FOLDERID_RoamingAppData when they
are sure doing so does not corrupt the roaming profile...

> g_get_tmp_dir uses environment variables, which are discouraged on Windows - it
> would be better to use the result of GetTempPath API.

Fixed in the branch mentioned in comment #2

> t feels safer to follow the principle of least surprise and behave
> the same on win32, leaving it up to application authors to make
> an informed decision and call SHGetFolderPathW passing CSIDL_APPDATA
> or SHGetKnownFolderPath passing FOLDERID_RoamingAppData when they
> are sure doing so does not corrupt the roaming profile...

I still think CSIDL_APPDATA is a better choice - very few programs actually make use of CSIDL_LOCAL_APPDATA, most just use CSIDL_APPDATA, so it's become kind of standard location for this (and the type of things that does go in CSIDL_LOCAL_APPDATA is pretty much non-essential stuff, which would fit $XDG_CACHE_HOME).

(In reply to comment #4)
> I still think CSIDL_APPDATA is a better choice - very few programs actually
> make use of CSIDL_LOCAL_APPDATA, most just use CSIDL_APPDATA, so it's become
> kind of standard location for this (and the type of things that does go in
> CSIDL_LOCAL_APPDATA is pretty much non-essential stuff, which would fit
> $XDG_CACHE_HOME).

Yes, I fully agree with CLIDL_APPDATA being a better fit for most,
but not all, data when it comes to g_get_user_data_dir(). The issue
here is that we have to provide a safe default for all users of GLib,
which currently being based on the XDG Base Directory specification
does not have the concept of local and roaming data to begin with.

Here's one example where roaming seems like a bad idea:
gegl, gedit and others use g_get_user_data_dir() to go search
for plugins. does it make sense to let plugins roam on multiple
computers while they might only have been installed on one (plugins
can come in their own separate installer, for example)?

Another example where things will eventually go wrong for somebody
is multiple active sessions, where it is not impossible for one session
to go and write stuff at log off the other session might not expect.
Due to GLib not being aware of local/roaming concepts, no code out there
using these utility functions is aware of this behavior by default. And
let's be honest, stuff is mostly written for Linux first and only then
ported to win32, usually without giving issues like this much thought.

So it still looks to me like using CSIDL_APPDATA should be something
application authors need to decide for themselves (like inkscape seems
to be doing) when they are sure doing so doesn't break stuff. But using
it by default for everything only provides for a pretty interesting source
of bug reports nobody is going to be able to reproduce. This again all
depends on the type of data off course, for example for icons it doesn't
matter at all, but the plugins thing is a different matter...

I would expect that g_get_user_cache_dir returns the same then the Path.GetTempPath-Method from Microsoft on windows:

https://msdn.microsoft.com/library/system.io.path.gettemppath(v=vs.110).aspx

This method checks for the existence of environment variables in the following order and uses the first path found:

 1. The path specified by the TMP environment variable.
 2. The path specified by the TEMP environment variable.
 3. The path specified by the USERPROFILE environment variable.
 4. The Windows directory.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/452.