Re: Trash system



Ryan Muldoon wrote:
> 
> One area of collaboration between GNOME and KDE (and other desktops) is
> handling of Trash.  I'm sure that Konqueror, Nautilus, and EFM all
> implement Trash differently, and this will likely cause user
> confusion.  I shouldn't have to think about which filemanager I used to
> delete a file that I need to recover.  A standard method for free
> desktops to handle trash would be a pretty easy area of collaboration
> with tangible results.  On the face of it, there are at least two
> issues: Location of Trash, and metadata for the trash.  The location
> would probably be easy to agree on, but metadata might be a sticking
> point.  I'd be very happy to see some effort to make a common solution
> though - it seems Trash handling is along the same lines as DnD and
> Cut+Paste for users - an everyday basic function that would be annoying
> to have to think about.  Trash should (ideally) just be trash.
> 
> Of course, a more ambitious goal would be to implement whatever is
> decided in GNU "rm" to have a wholly consistent behavior on free
> systems, but one step at a time.
> 
> Hopefully this email is of some use....
> 

Hey Ryan,

It would be really cool to unify the Trash system between the two
desktops.

I worked a bunch on Trash in Nautilus and would very much like to
cooperate on this.

We use multiple Trash directories on all the partitions that the user
tries to delete items and present them as a unified virtual directory in
Nautilus.

We have quite an elaborate heuristic that picks the location of the
actual physical trash directories on the different partitions. 

While it is really easy to place a Trash directory into your home
directory for trashed items from the same partition (we use ~/.Trash),
it's harder to pick a good place on the other ext2, etc. disks because
there is no standard. 

We create Trash directories on the other partitions as needed, first
time a user actually tries to delete something. This helps find a good
location that is actually user-writable. Our heuristic starts looking
for a user-writable location in the same directory as the original
trashed item and continues going up in the partition hierarchy, trying
to place the trash directory as close to the partition's root as
possible. We then create a trash directory in that place, it is in the
form ".Trash-<user_name>", eg. ".Trash-pavel" and we cache the location
of it so we know where the Trash is next time. If the user mounts a
partition that has not been mounted before (no cached Trash location),
we search for the Trash on it first - it could have had Trash from a
different system and we want to reuse that.

This way we end up not trying to create trash on disks that have no
user-owned (and therefore user-deletable) files, we can deal with a
directory that contains user-owned items on a partition that is
otherwise root owned, etc.

This heuristic is designed to deal with the flexible and free form
nature of partitions on Linux and unix systems. It would be much easier,
of course, if there was a standard on Trash directory placement on
partitions that most file managers adhered to which defined a single
location for Trash on each of the partitions. I'd be more than happy to
get rid of our complex heuristic if that were the case.

How does Konqueror go about placing Trash directories? 

Besides that, I was going to add more support in to recognize Windows
and maybe even Mac Trash, either should be easy because on those systems
Trash is in a well known place.

As far as metadata for Trash, we are planning to store the original item
locations but have not implemented the feature yet so it would be really
easy to adopt any solution that you may already have. Any other metadata
besides the original location?

Pavel




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]