Opened 10 years ago

Closed 10 years ago

#4210 closed Enhancement (wontfix)

Please save state information under ~/.local instead of ~/.config

Reported by: costela Owned by:
Priority: Low Milestone: None Set
Component: Transmission Version: 2.22
Severity: Minor Keywords: config state
Cc:

Description

Hi,

This is kinda self-explanatory. It would be nice to save state information under ~/.local instead of ~/.config, to make sharing of configs easier.

Originally reported here: http://bugs.debian.org/623998

Cheers

Change History (18)

comment:1 Changed 10 years ago by jordan

Hi Leo,

Thanks for bumping this upstream but I'm really not sure what to do with this. If the OP would clarify which files he thinks which specific files should be moved to .local it would be easier to respond.

comment:2 Changed 10 years ago by costela

Hi,

Well, the way I see it, everything but settings.json could be moved to .local, since it's all really local state information (torrents, dht.dat, stats.json, etc). The settings.json file can be shared between many computers, the rest not really. I can't say for the OP, but I can imagine wanting to backup your .config among many machines and having it constantly change state because some program is using it like /var/run. That would be pretty annoying.

But again: this is hardly an important bug. I just figured it was worth looking into, given a bit of that precious - and almost mythological - free time! :)

comment:3 Changed 10 years ago by jordan

  • Resolution set to duplicate
  • Status changed from new to closed

Closing as a duplicate of #684 then.

comment:4 Changed 10 years ago by costela

Bug that bug is marked as "fixed", AFAICS because transmission started using .config, which is a good thing, of course, but doesn't address the issue here.

So I'd say either reopen #684 or leave this one open for consideration.

comment:5 Changed 10 years ago by costela

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Since nobody commented on my last answer, I'm reopening the ticket until further notice.

comment:6 Changed 10 years ago by jordan

  • Resolution set to duplicate
  • Status changed from reopened to closed

You're not looking then. The issue here is directly addressed by ticket #684 in comments 7 through 18.

It's true that extra topic was added after the ticket was closed -- but it's a moot point. It's my opinion that the desire to use .local is based on a misunderstanding of the XDG spec (see https://trac.transmissionbt.com/ticket/684#comment:14) and the XDG people have not yet chosen to clarify the question.

comment:7 Changed 10 years ago by costela

  • Resolution duplicate deleted
  • Status changed from closed to reopened

No, the desire to use .local is based on the practical issue of sharing configs across different machines, while not sharing state information, which might very well be specific to the local machine. This might not be my personal use-case, but that doesn't mean it's not valid. (e.g.: you might want to share your .config between your home and work computers, but wouldn't really want to have your current home downloads to start when you just want to download some work-related ISO at your office)

Whether or not the spec is ambiguous doesn't make this issue disappear, so closing the bug simply sends the message that you don't care about that specific use-case. Don't get me wrong: if you - or Charles, or Krzysztof - really don't care about this use-case, just say so, that's totally understandable. Just don't dismiss it blaming the XDG spec.

And even if you consider the spec's ambiguity, there's still plenty of reasons to adopt this suggestion, since both KDE and Gnome have similar proposed interpretations:

http://ploum.net/post/207-modify-your-application-to-use-xdg-folders (referenced from http://live.gnome.org/GnomeGoals/XDGConfigFolders)

http://techbase.kde.org/KDE_System_Administration/XDG_Filesystem_Hierarchy

Both stress the need for separating config from data and even if the still leave room for interpretation in some cases, others are perfectly clear, like the fact that stats.json, dht.dat and the whole blocklists directory belong in XDG_CACHE_HOME.

comment:8 Changed 10 years ago by jordan

How do the blocklists and stats.json belong in the cache directory?

comment:9 Changed 10 years ago by costela

AFAICT they can't be generated manually (at least not practically) and get updated automatically. So, according to the Gnome interpretation cited above: what would happen if both went missing? At worst the user would think "wow, this is slow". And according to the KDE interpretation: they're both temporary files, in the sense that they get periodically overwritten.

Or is it possible (and practical) to manage dht.dat and blocklists manually? I imagine one could manually download different blocklists, but is this a realistic use-case? (this is not a rhetorical question)

As for stats.json, is it used for anything other than information? If so, then you probably got a point that it doesn't belong in XDG_CACHE_HOME.

comment:10 Changed 10 years ago by livings124

Neither of those files are cache files. A file being updatable doesn't mean it's a cache file.

comment:11 follow-up: Changed 10 years ago by jordan

dht.dat probably does belong in the cache directory.

I don't think stats.json or blocklists do, though. Losing the latter could be a privacy issue rather than a "wow this is slow" issue, so it should reside in a directory where backups are made.

comment:12 in reply to: ↑ 11 Changed 10 years ago by costela

Replying to jordan:

Losing the latter could be a privacy issue rather than a "wow this is slow" issue, so it should reside in a directory where backups are made.

I don't think I understand what you mean by "privacy issue". More specifically: I don't see the connection between something being private and something being backed-up. E.g.: I'd consider my browser cookies private, but not really something that would make sense to back up (though I do imagine there are people out there who actually do backup their cookies... :) ).

Having my cookies copied would obviously be an issue, but simply losing them (as in "accidentally deleted", "expired", etc) would be just a matter of "oh damn, have to log in again!". However, this analogy doesn't really cut it, because losing your blocklist wouldn't even mean you have to *do* anything. You just wait a couple of seconds longer until it gets downloaded again.

But here I have to come back to my question from a few messages back: is there actually a practical situation where users *manually* manage their blocklists? I've always assumed a user either uses the automatic download feature or simply doesn't use blocklists, but if that assumption is false then my argument has significantly less weight.

comment:13 Changed 10 years ago by livings124

Users can add their own blocklists, as well as modify existing to add additional addresses.

comment:14 Changed 10 years ago by costela

Indeed, but according to https://trac.transmissionbt.com/wiki/Blocklists, the .bin files are generated on the fly "for quick lookups" (or downloaded), so putting at least this subset of files in XDG_CACHE_HOME still makes sense.

comment:15 Changed 10 years ago by livings124

You're overanalyzing the wording. A blocklist is not a cache file. If a user doesn't have the auto-update feature on, deleting it deletes it for good. It's not a temporary store to speed things up - it's the actual list.

comment:16 Changed 10 years ago by platina5

Please... don't move it from .config to .local. Most applications that no longer put their files directly into the home directory use .config now. If you need .local too, why not simply symlink it?

comment:17 Changed 10 years ago by platina5

Disregard my last comment, i misread something and actually might be in favour of this suggestion.

comment:18 Changed 10 years ago by jordan

  • Resolution set to wontfix
  • Status changed from reopened to closed

I spent about half an hour this morning implementing the "cache" aspect of this (g_get_user_cache_dir() for the GTK+ client, QDesktopServices::CacheLocation for the Qt client, etc.) and got into testing before I realized something that should have been obvious to begin with:

If the different directories are decoupled, that makes it much more difficult to run multiple copies of Transmission -- a not-uncommon event on seedboxes.

To run multiple instances now, you pass a different config directory on the command-line (such as transmission-daemon -g /path/to/config-dir). Since the cache files are relative to that directory, that's sufficient.

If we decouple the cache directory's location, the cache files are shared between instances. This is harmless for some files (favicons) but harmful for others (dht.dat). A workaround would be to require users to specify a cache directory as a command line argument, but that makes things more complicated for both users and administrators, going against the goals of this ticket.

I appreciate the goals of this ticket, but don't see how it would work in practice.

Note: See TracTickets for help on using tickets.