Modify

Opened 6 years ago

Closed 5 months ago

Last modified 5 months ago

#6664 closed enhancement (fixed)

Josm config files should be in $XDG_CONFIG_HOME instead of ~/.josm

Reported by: anonymous Owned by: team
Priority: normal Milestone: 16.10
Component: Core Version:
Keywords: Cc: spam-josmtrac@…, AMDmi3

Description (last modified by bastiK)

Josm configuration and user files should be in $XDG_CONFIG_HOME and $XDG_DATA_HOME respectively, as described in the XDG Base Directory Specification: <http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html>.

Josm stores its user files in ~/.josm, instead. This clutters the $HOME directory and makes it hard to backup Josm's settings in a easy way.

Attachments (1)

xdg-base-dirs.patch (2.5 KB) - added by bastiK 5 months ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 6 years ago by olejorgenb

A workaround is to run josm as:

APPDATA=$XDG_CONFIG_HOME java -jar josm.jar

comment:2 Changed 6 years ago by bastiK

So it would look like this (just using the default paths for simplicity):

~/.josm/motd.html           --> ~/.cache/josm/
~/.josm/plugins/site-josm.openstreetmap.de-_plugins.txt
                            --> ~/.cache/josm/
~/.josm/mirror_http___planet.openstreetmap.org_users_agreed_users_agreed.txt 
                            --> ~/.cache/josm/
(and other mirror files the same)
~/.josm/wms-cache           --> ~/.cache/josm/wms
~/.josm/imagery/cache       --> ~/.cache/josm/imagery

~/.josm/autosave            --> ~/.local/share/josm/
~/.josm/plugins/*.jar       --> ~/.local/share/josm/plugins/

~/.josm/preferences         --> ~/.config/josm/

Same applies for plugins that currently put all their stuff in ~/.josm/plugins/PLUGIN_NAME.

---

Not sure if it is a particularly good idea, though. Sometimes JOSM breaks due to a corrupt cache file or a certain configuration option triggers a serious bug. Then we tell people to simply remove their ~/.josm or %appdata%/JOSM folder respectively. For a stable software, this kind of radical measure shouldn't be necessary. But JOSM is constantly evolving and we do our best, but we don't have enough man power to care for super-stable interfaces.

Now, when configuration, data and cache files are spread over multiple folders, it is cumbersome to reset the state completely. It is much simpler if everything is at one place.

comment:3 in reply to:  1 Changed 6 years ago by bastiK

Replying to olejorgenb:

A workaround is to run josm as:

APPDATA=$XDG_CONFIG_HOME java -jar josm.jar

I'd write java -Djosm.home=$XDG_CONFIG_HOME -jar dist/josm.jar.

comment:4 in reply to:  2 Changed 6 years ago by anonymous

Replying to bastiK:

Same applies for plugins that currently put all their stuff in ~/.josm/plugins/PLUGIN_NAME.

Wouldn't it be better to expose some API to the plugins like File getConfigDir(), File getDataDir(), File getCacheDir()?

Not sure if it is a particularly good idea, though. Sometimes JOSM breaks due to a corrupt cache file or a certain configuration option triggers a serious bug. Then we tell people to simply remove their ~/.josm or %appdata%/JOSM folder respectively. For a stable software, this kind of radical measure shouldn't be necessary. But JOSM is constantly evolving and we do our best, but we don't have enough man power to care for super-stable interfaces.

Now, when configuration, data and cache files are spread over multiple folders it is cumbersome to reset the state completely. It is much simpler if everything is at one place.

Wouldn't instead be easier to say "First remove ~/.cache/josm. If that did not work, try removing ~/.config/josm. Is the problem solved now? Did you need to remove the config or was the cache enough?" You would get much better bug replies with that.

I wouldn't mind removing only my cache first, instead of losing all my configuration.

Anyway, if you need a quick workaround, please use java -Djosm.home=${XDG_DATA_HOME:-~/.local/share/} -jar dist/josm.jar, so that all the files end up in the DATA dir, not CONFIG dir (that is often backed up and treated as a collection text files).

comment:5 Changed 6 years ago by bastiK

I could imagine, that we have getConfigDir(), getDataDir() and getCacheDir() in JOSM core and they all point to ~/.josm or %APPDATA%/JOSM by default. In addition to -Djosm.home there would be 3 more switches to configure these folders as desired.

comment:6 Changed 6 years ago by bastiK

Type: defectenhancement

comment:7 Changed 5 years ago by bastiK

Description: modified (diff)

Introduced global cache folder ~/.josm/cache (see [4810], [4812], [4813]).

You can write a run script that makes JOSM use the XDG folders.

Example:

java -Djosm.home=$XDG_CONFIG_HOME -Djosm.cache=$XDG_CACHE_HOME -jar josm.jar

TODO: user data in a separate folder ($XDG_DATA_HOME)

Last edited 5 years ago by bastiK (previous) (diff)

comment:8 Changed 2 years ago by Don-vip

Milestone: 14.11

comment:9 Changed 2 years ago by stoecker

Resolution: wontfix
Status: newclosed

Actually this is a 3 year old bug nobody cared about. I'd simply close it. ~/.josm is a good choice. Cluttering the files over multiple directories OTOH not. Also $XDG_DATA_HOME and $XDG_CONFIG_HOME aren't necessary defined. They are optional.

comment:10 Changed 2 years ago by Don-vip

Milestone: 14.11

There's a lot of old tickets with good ideas but ok :) It's simpler if we stick to our current folder (except shared tile cache).

comment:11 in reply to:  10 Changed 2 years ago by stoecker

Replying to Don-vip:

There's a lot of old tickets with good ideas but ok :)

I know. That's the reason why they aren't closed, but ...

It's simpler if we stick to our current folder (except shared tile cache).

... sometimes proposed changes are only different and not necessarily better :-)

comment:12 Changed 2 years ago by Don-vip

Ticket #11365 has been marked as a duplicate of this ticket.

comment:13 Changed 5 months ago by bastiK

Ticket #13835 has been marked as a duplicate of this ticket.

comment:14 Changed 5 months ago by bastiK

Resolution: wontfix
Status: closedreopened

Preferences, user data and cache are in separate locations on OS X since [7829]. On Windows, the cache is in a separate location (also since [7829]). This setup seems to cause no major problems for almost 2 years now.

#11365 and #13835 raise a valid point: It is much easier and more predictable to set up a backup system if JOSM puts its cache (including huge imagery tile cache) in ~/.cache/josm. There was a similar reason to move the cache to the dedicated location on Windows (#9707).

Currently, Linux is the odd one out. It would be more consistent across operating systems, if we implement the XDG base directory standard on Linux. One may like this standard or not, but it is adopted by more and more applications nowadays. (Seems like > 50% to me.)

I suggest to rethink this topic and see if the old arguments still apply. (JOSM is a bit more stable now, it seems ...)

Changed 5 months ago by bastiK

Attachment: xdg-base-dirs.patch added

comment:15 Changed 5 months ago by bastiK

Patch looks for existing ~/.josm directory. If found, places everything there (as it does now). Otherwise the XDG directories are used (~/.cache/JOSM, ~/.local/share/JOSM, ~/.config/JOSM).

comment:16 Changed 5 months ago by bastiK

Resolution: fixed
Status: reopenedclosed

In 11162/josm:

fixed #6664 - use XDG Base Directory Specification on Linux

If existing ~/.josm directory is found, it will be used as before.
Otherwise, ~/.cache/JOSM, ~/.local/share/JOSM and
~/.config/JOSM are used for cache, user data and preferences.

New system property option -Djosm.dir.name=... to change this to
~/.cache/JOSM-latest, etc. for the josm-latest package.

comment:17 Changed 5 months ago by simon04

Milestone: 16.10

comment:18 Changed 5 months ago by simon04

Cc: spam-josmtrac@… AMDmi3 added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.