[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Konqueror delete unification
From:       Koos Vriezen <koos.vriezen () xs4all ! nl>
Date:       2003-07-16 12:49:33
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic