Transmission should use XDG_DATA_HOME and XDG_CACHE_HOME for non-config user files

[Gioele Barabucci]

Binary package hint: transmission

Currently, version 1.75, Transmission stores many files in XDG_CONFIG_HOME that should be in other directories.

These files should be moved to XDG_DATA_HOME or XDG_CACHE_HOME:

  stats.json
  torrents/*
  blocklists/*
  dht.dat
  lock
  resume/*

None of these files belongs to XDG_CONFIG_HOME that is "a single base directory relative to which user-specific configuration files should be written" as specified in <http://standards.freedesktop.org/basedir-spec/latest/>.

[Krzysztof Klimonda (kklimonda)]

Agreed, It's mostly matter of deciding what files belongs where..

[Charles Kerr (charlesk)]

The intention of XDG_DATA_HOME vs XDG_CONFIG_HOME is that the former should only be written to when installing software. That way the directory is relatively constant, which makes backups easier for system administrators. By contrast, XDG_DATA_HOME is where all the frequently-changed or short-term files go.

Given the short-term nature of .torrent files, IMO they're a better fit for XDG_CONFIG_HOME. They *definitely* aren't files written once when installing software.

For more information, see the links in http://trac.transmissionbt.com/ticket/684#comment:14

[Krzysztof Klimonda (kklimonda)]

After some more discussion with Charles on #transmission I've decided to reopen this bug.
   - The only files, we have agreed upon, that can be moved are dht.dat and lock and they should go to CACHE_HOME
   - It would be possible to also move level1.bin from blocklists/ to CACHE_HOME, the main problem we face is the possibility of redownloading this file from transmission servers too often. CONFIG_HOME/transmission/blocklists/ would still be there for custom blocklists created by users.
   - This issue is really low priority. Only if someone decides to write a good patch it's going to be implemented.

[Charles Kerr (charlesk)]

xref: http://<email address hidden>/9346540.html

<quote>

The spec says:

"There is a single base directory relative to which user-specific data
files should be written. This directory is defined by the environment
variable $XDG_DATA_HOME."

I think "user-specific data" is very confusing here.

However, the default user (~/.local/share) and system (/usr/local/share/:/
usr/share/) paths indicate what it is really for. In other words, it is
for things that could reasonably go in /usr/share.

Or, for what would result if you did:

  $ ./configure --prefix=$HOME/.local/ && make install

> But Transmission developer (Charle at
> http://trac.transmissionbt.com/ticket/684 ) has understood (concerning
> files in $HOME/.transmission/torrents/ ) that "the intention of
> XDG_DATA_HOME vs XDG_CONFIG_HOME is that the former should only be
> written to when installing software. That way the directory is
> relatively constant, which makes backups easier for system
> administrators.

Correct.

</quote>

[Charles Kerr (charlesk)]

Updating the summary to reflect the new goals of the ticket.

[Mark Shuttleworth (sabdfl)]

I'm not sure I understand why XDG_DATA_HOME is "only supposed to be written at install time"? I makes sense to me that:

 - config is config
 - cache is data that can be thrown away without prejudicing the user experience other than performance
 - data is data that the app writes during the users use of it, which is not data that the user explicitly saved somewhere (i.e. not data the user would open through File->Open).

[Charles Kerr (charlesk)]

This topic has been discussed a few times on the XDG mailing list due to peoples' different interpretations. Perhaps the best scenario would be for an updated spec to remove ambiguity.

Until that happens, previous discussions on the XDG mailing list indicate that XDG_DATA_HOME was intended as a user-writable version of /usr/share so users can override icons, themes, etc. that are in /usr/share. Following that parallel, in general you wouldn't want applications writing to XDG_DATA_HOME any more than to /usr/share. (There are exceptions, as ~/.local/Trash shows.)

Here are some previous XDG discussions of XDG_DATA_HOME that shed light:

Thomas Leonard @ http://lists.freedesktop.org/archives/xdg/2003-July/000195.html

    Ideally, DATA should only be written to when installing software. The user
    should only have to backup CONFIG. Or at least, that was my impression.
    The spec doesn't actually say what they're for ;-)

David Faure @ http://lists.freedesktop.org/archives/xdg/2008-July/009748.html

    Everything I find in my ~/.local/share is really either a local equivalent of /usr/share stuff,
    or something that is really user data only with no system-wide equivalent.
    ~/.local/share/applications has desktop files, ~/.local/share/mime has mimetypes (like /usr/share/mime), etc.

Mark McLoughlin @ http://lists.freedesktop.org/archives/xdg/2005-May/005315.html

    My take on this would be that editors shouldn't be editing .desktop
    files by making a copy with the same file ID and putting them in
    ~/.local/share/applications. $XDG_DATA_HOME, AFAICT, is for application
    data, not user configuration files.

    To show a concrete problem with doing it this way, if you installed a
    vim package in your home directory, you'd expect the package to install
    vim.desktop in ~/.local/share/applications, overriding the user's
    changes.

Thomas Leonard @ http://lists.freedesktop.org/archives/xdg/2008-June/009678.html says:

    > But Transmission developer (Charles at
    > http://trac.transmissionbt.com/ticket/684 ) has understood (concerning
    > files in $HOME/.transmission/torrents/ ) that "the intention of
    > XDG_DATA_HOME vs XDG_CONFIG_HOME is that the former should only be
    > written to when installing software. That way the directory is
    > relatively constant, which makes backups easier for system
    > administrators.

    Correct.

    > By contrast, XDG_CONFIG_HOME is where all the
    > frequently-changed or short-term files go. Given the short-term nature
    > of .torrent files, IMO they're a better fit for XDG_CONFIG_HOME. They
    > *definitely* aren't files written once when installing software."

    Some of these should probably go in $XDG_CACHE_HOME instead (things
    that could be downloaded again easily, for example).

[Charles Kerr (charlesk)]

/me makes a note to not indent lines in LP anymore. sorry for the wrap. :)

[Charles Kerr (charlesk)]

Other navel-gazing about the meaning of XDG_DATA_HOME:

http://groups.google.com/g/f477fc85/t/d5422f89f6d8eb72/d/2bd74765e1d1c0b8

MS asked Waldo to clarify the spec, which yielded this response: http://<email address hidden>/msg02066.html ... which, at least to me, doesn't really clarify things wrt XDG_DATA_HOME.

Anyway, 2.0 is now using XDG_CACHE_HOME correctly, and in the absence of any new information I think we are using XDG_DATA_HOME properly by not using it at all for files changed post-installation. I think this ticket can be tied to the "upgrade to >= 2.0" ticket.

[Krzysztof Klimonda (kklimonda)]

I agree, as long as no new info about XDG_DATA_HOME is available the current behaviour is as good as it can get. Fixed in 2.00