controlling location of trash on per-filesystem basis?

[D. R. Evans]

Duncan wrote on 05/12/2016 03:08 AM:

> I believe I read somewhere, and it makes sense, that the trash mechanism 
> will try to create that .Trash dir at the root of whatever filesystem, 
> and will use it if it can do so.
>

> But if permissions at the root of that filesystem are such that the trash 
> dir can't be created there, the location in $XDG_DATA_HOME (~/.local/
> share being the default location if the var isn't set) will be used 
> instead.
> 
> If that is indeed the case, all you need to do to on filesystems you 
> don't want trash dirs to appear on is arrange for the filesystem root dir 
> to be owned by some other user, say root, and set read-only for the 
> normal user(s) that would otherwise be creating and trashing files on 
> that filesystem, so they can't create their trash dirs.  

It isn't practical for me to make it so that the root dir in the filesystems
isn't writeable by the user, since the user has to be able to create and
manipulate files at that level.

> Alternatively, if you want the filesystem's root dir to be owned by root 
> and not writable by the users, but still want them to be able to put 
> their trash there, pre-create the trash dirs and chown them to the 
> appropriate user.
> 

That doesn't work for me, for the same reason.

I suppose I could try setting the permissions of the .Trash directories so
that the user can't use them, though. That might work. But it would still be
messier than a proper configuration that says "don't try to create Trash on
filesystem <xxx> but use the home Trash instead for that filesystem". Surely
there must be some way to do that.

(Indeed, there must be a way to say "don't use Trash at all on filesystem
<xxx>", but I can't find a way to do that either.)

  Doc

-- 
Web:  http://www.sff.net/people/N7DR

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde/attachments/20160512/946a191b/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.