XDG base directories and trash outside $HOME device

[Maurício Antunes]

Hi,

XDG base directory specification [1] doesn't state that $XDG_DATA_HOME
should reside at a specific device, like, say, the same device as
$HOME is (I usually direct it to what 'mktemp -d' gives me when I log
in, which will be inside /tmp). XDG trash can specification says that
the user's "home trash" location is $XDG_DATA_HOME/Trash, and that it
"should function as the user's main trash directory. Files that the user
trashes from the same file system (device/partition) should be stored
here." [2] However, if $XDG_DATA_HOME is not in the same filesystem as
where an user saves most of his files, the home trash is not going to
be his main trash directory (in the sense that most of his files are
not going to end there).

I've found a bug in glib's GIO function g_local_file_trash [3], which
fails to find a trash directory for files in $HOME when $XDG_DATA_HOME
is not in the same device. Before I submit a patch, though, I would like
to check if my assumptions are right:

Is it okay to have $XDG_DATA_HOME in a device that is not the same
as $HOME?

Should not that trash spec quote be refrased to say just that the "home
trash" should always be used for files trashed in the same device,
but not that it's an user's main trash dir?

Thanks,
Maurício

[1]: http://standards.freedesktop.org/basedir-spec/latest
[2]: http://www.ramendik.ru/docs/trashspec.html
[3]: https://git.gnome.org/browse/glib/tree/gio/glocalfile.c

[David Faure]

Post by Maurício Antunes
Is it okay to have $XDG_DATA_HOME in a device that is not the same
as $HOME?

It's unusual, but I don't see anything that would forbid it.

Post by Maurício Antunes
Should not that trash spec quote be refrased to say just that the "home
trash" should always be used for files trashed in the same device,
but not that it's an user's main trash dir?

I have no objection to this spec change.
The word "main" doesn't mean much anyway.
The phrase "home trash" is clear (and represents a trash directory with a
differently constructed path from the other ones), you just have to ensure the
spec never says that it's necessarily for trashing the files from home even if
that's the most common use case for it :-)

[Ryan Lortie]

hi,

Post by David Faure

Post by Maurício Antunes
Is it okay to have $XDG_DATA_HOME in a device that is not the same
as $HOME?

It's unusual, but I don't see anything that would forbid it.

Post by Maurício Antunes
Should not that trash spec quote be refrased to say just that the "home
trash" should always be used for files trashed in the same device,
but not that it's an user's main trash dir?

I have no objection to this spec change.

I'd actually prefer to take this chance to update the XDG basedir
specification to mandate that $HOME and each of the $XDG_*_HOME
variables are all on the same filesystem, with the XDG_* variables
contained within $HOME.

I think we should be aiming to reduce complexity in this area -- not
increase it. Having XDG_DATA_DIRS available for expansion by the user
has shown itself to be extremely useful, but the only place that
XDG_*_HOME variables have presented themselves as truly useful is in the
construction of test sandboxes -- and those sandboxes could just as well
be constructed by way of setting $HOME directly.

I'm not suggesting that we should claw this back now and start
hardcoding ~/.config and ~/.local/share anywhere -- but I am suggesting
that maybe this level of configurability was a mistake. We have to live
with that now, but we should not go out of our way to change the specs
in ways to encourage further use of these features.

Cheers

[Maurício Antunes]

Post by Ryan Lortie
I'd actually prefer to take this chance to update the XDG basedir
specification to mandate that $HOME and each of the $XDG_*_HOME
variables are all on the same filesystem, with the XDG_* variables
contained within $HOME.

Oh, I was so happy when I realized I could get rid of all those
directories that kept popping from time to time just by pointing all of
XDG_* to somewhere inside $(mktemp -d). Please don't take that from me!

Best,
Maurício

[David Faure]

Post by Maurício Antunes

Post by Ryan Lortie
I'd actually prefer to take this chance to update the XDG basedir
specification to mandate that $HOME and each of the $XDG_*_HOME
variables are all on the same filesystem, with the XDG_* variables
contained within $HOME.

Oh, I was so happy when I realized I could get rid of all those
directories that kept popping from time to time just by pointing all of
XDG_* to somewhere inside $(mktemp -d). Please don't take that from me!

What's the use case for not being able save configuration at all, from one run
to the next?

[Maurício Antunes]

Post by David Faure

Post by Maurício Antunes
Oh, I was so happy when I realized I could get rid of all
those directories that kept popping from time to time just by
pointing all of XDG_* to somewhere inside $(mktemp -d). Please
don't take that from me!

What's the use case for not being able save configuration at
all, from one run to the next?

Configuration files quickly become bloated by settings I do not
want. Those configurations I do want I set with gsettings, in
an initialization script which is kept synchronized everywhere
I go through a git repository:

gsettings set org.gnome.desktop.wm.preferences audible-bell false
gsettings set org.gnome.nautilus.icon-view captions
[\'mime_type\',\'permissions\',\'size\']
gsettings set org.gnome.nautilus.list-view default-column-order
[\'name\',\'mime_type\',\'permissions\',\'size\']
gsettings set org.gnome.nautilus.list-view default-visible-columns
[\'name\',\'mime_type\',\'permissions\',\'size\']
gsettings set org.gnome.nautilus.list-view use-tree-view true
etc.

This also allows me to experiment freely with configuration,
knowing in advance that everything will be reset after my next
logging in.

I don't think the designers of the base dir spec expected
users to behave that way. It would be nice if someone who
participated in the process could write a rationale. Most of
the discussion goes back to the first years of the last decade,
and I found it difficult to try to figure out the reasons
behind most decisions just by reading this list archives.

Best,
Maurício