dank at alumni.caltech.edu
Thu Dec 14 06:39:13 PST 2000
The following sounds like an issue for the LSB, maybe.
Pavel Cisler wrote:
> 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.
> It would be really cool to unify the Trash system between the two
> 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
> 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.
More information about the lsb-discuss