Trash spec 0.2, technical questions
alexl at redhat.com
Thu Sep 2 10:39:08 EEST 2004
On Wed, 2004-09-01 at 16:36 +0200, C. Gatzemeier wrote:
> I looked at your list of good and bad things again. What do you think
> the following list of possible ways for improvments:
> - "full path trashes" (permissions, orig. locations always
> - "timestamping" (name collisions, date of deletion always
> - /Trash optionaly hidden or not (appearance in different UIs / OSs)
> - have separate trash storage and indexing spec parts (the former
> getting more
> centralized as privileges rise, the latter getting more shared as
I don't like the full path trashes, or the timestamping.
I don't quite see the point of having Trash visible. Even in a shell i
wouldn't want to see files i removed, instead i'd prefer a tool for it.
The trash is just a hidden backup so that I can recover from problems,
not something you normally think about. It just adds lots of complexity
to the spec, and failure modes where some implementation doesn't find
the trash, or you get double trash dirs.
I'm not sure what separate storage and indexing spec parts would mean,
but it strikes me as overcomplicating things a lot.
Alexander Larsson Red Hat, Inc
alexl at redhat.com alla at lysator.liu.se
He's an ungodly soccer-playing paramedic fleeing from a secret government
programme. She's a strong-willed paranoid detective on the trail of a serial
killer. They fight crime!
More information about the xdg