Trash mechanism

[David Faure]

On Thursday 26 August 2004 14:22, Alexander Larsson wrote:
> Nautilus does in fact have a preference called "Include a Delete command
> that bypasses Trash" that lets you get both operation. But in my opinion
> thats not a very elegant solution. You force the user to learn the
> difference and think about which one to use when they delete files.
Yes - but I prefer that over trying to guess what they really want to do.

> Which one does KDE bind to the delete key btw? Thats likely to be used
> often (without thinking about which form of delete that causes).
By default Del moves to trash, Shift+Del deletes.

> Sure, we just have to remember that the implementations here might
> differ a bit in the exact details, so we can't rely on both getting
> things exactly the same.
Sure (but I don't think that matters)

> > > You mention "generated name" for the tempfile, but in like 99% of all
> > > cases there won't be a collision, and i think using the real name is
> > > helpful if you ever manually look into the trash dir. If the real name
> > > doesn't work, using some algorithm like appending " (copy $n)" or
> > > something should work fine.
> > Hmm. In theory that's opening for race conditions (if multiple programs
> > try trashing a file with same name at the same time - this is because we'll 
> > be doing this in a kioslave, i.e. letting several programs benefit from this,
> > in particular kdesktop and konqueror initially). But of course since trashing
> > a file is a user-requested operation, he'd have to be pretty fast with his mouse :)
> 
> How is this different from the case of a random filename? Two files
> could accidentally pick the same random filename. 
[Not when using the standard method of creating a tempfile (that'd be KTempFile for me :)
Sorry, I shouldn't use existing kde solutions as a reason for a design 
decision in a cross-desktop standard. It's just that I tend to know the
available C++ better solutions better than the C functions they rely on :/]

> The race condition is always there, and is solved the same way 
> mkstemp solves it, by using O_EXCL. 
OK, I see. Will do that then.

> [...]
> > The user creating the .Trash directory would need to make it world-writable, right?
> 
> Yeah. We should probably also make it world unreadable and with sticky
> bit (like /tmp) so that you can't look at it, and rename or remove other
> peoples trash dirs. Of course, even with the sticky bit set the person
> who creates the .Trash dir can still rename/remove other users trash
> dirs. I dunno what to do about that.

Waldo suggested the following solution:
we should make a small suid-root program that creates $topdir/.Trash and 
$topdir/.Trash/$uid for the user calling that program. This solves the
problem you mention (deleting other people's $uid dirs) as well as another
similar problem (creating a $uid dir before the other user can do it, effectively
preventing him from doing it).
I suck at writing suid-root programs though - maybe this is something
you (or any other C programmer who volunteers) could look into? :/

> What i mean by unless is that if you bring something from implemenation
> 'a' to implementation 'b' and 'a' chose to create a .Trash dir, then 'b'
> isn't free to choose whether to use it or not. To be interoperable we
> must always use the directory if there is one. When you handle
> "pristine" disks/media/whatever implemenation 'b' is free to do whatever
> he wants.
We agree 100%.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).