From kfm-devel  Wed Jul 16 12:49:33 2003
From: Koos Vriezen <koos.vriezen () xs4all ! nl>
Date: Wed, 16 Jul 2003 12:49:33 +0000
To: kfm-devel
Subject: Re: Konqueror delete unification
X-MARC-Message: https://marc.info/?l=kfm-devel&m=105835963626763

On Wed, 16 Jul 2003, David Faure wrote:

> On Wednesday 16 July 2003 14:10, Koos Vriezen wrote:
> > > Plus this doesn't solve the problems due to conflicting filenames
> > > (deleting a file with the same name in two directories).
> >
> > Imo, symlinking to ~/Trash is a bad idea (or there should be path info in
> > the symlink name). There might be a way to easily browse trash, but it's
> > a weak spot. 'find mounting-point -name .trash -type d' does makes it
> > possible though. To me, it's about what do you do the most, moving stuff
> > to trash or trying to get it out of there. And what you do the most
> > should be the fastest.
> > Moving stuff to ~/Trash has also the size weak spot, some files just don't
> > fit and du -s on dirs isn't convenient either.
> > There we have two ways with its deficits..
>
> Yes, you're comparing two bad solutions, omitting the good one :)
> * Just moving to .trash means listing the trash contents takes a big find -> bad
> * Moving to .trash and adding symlinks brings back the problem of conflicting filenames -> bad
> * Moving to a per-partition trash directory, which some kde config file would know
> about (so it doesn't need to "find" it), and having some medata info file at the
> toplevel pointing to a unique (random-generated) file/subdir, to solve the
> problem of conflicting filenames, is the idea in the gnome-kde thread, and IMHO
> the best one.
>
> Per-partition means no size problem, nor long copying. But requires some
> heuristics, it would help to get the exact algorithm from Nautilus since they've
> been doing that for some time.
> It's almost like the .trash idea, but if we register such dirs globally, there should
> be very few. If there's one per directory, then everytime a directory is moved
> or renamed, the dir can't be found anymore. At least with only one per partition
> this reduces that risk.

Totally agreed:) (I must have misread
http://urbanlizard.com/~aseigo/Trash_system_messages then) and ideal for
trash://. This will look like my earlier post, where you can install
(manually or by heuristics) trash on a fs (I rather speak of fs vs.
partition, covers loop and remotes better, nitpick I know).
Still, some scanning for removables/remotes might be usefull.

> > > I think the idea described in http://urbanlizard.com/~aseigo/Trash_system_messages
> > > is more complete (it includes the ability to see the date of deletion, and
> > > to restore the mtime of the file when restoring it, etc.), and it fixes those problems.
> >
> > So does moving to .trash, no?
>
> Where do you get the datetime of deletion, if you just move to .trash?

Ah, yes that's lost.

Koos