Konqueror delete unification

[Koos Vriezen]

On Fri, 18 Jul 2003, Jos van den Oever wrote:

> On Friday 18 July 2003 14:11, Koos Vriezen wrote:
> > I think you have a point, using a suid for restoring trash is dangerous.
> > Good reason for splitting this functionality like a untrash...and/or,
> > (un)trash forks, child changes uid and restores files, parent waits for
> > it and if succeeds sets permissions right (for restoring over fs
> > boundaries) and maybe edit trash meta data. No suid on untrash means
> > you can lose owner.group settings..but it's not the end of the world
> > either and only if a fs doesn't have a trash dir.
>
> You don't need to edit the metadata is agree that metadata can be removed by
> trash (not untrash) if a file is not in the trash. This slows down trash
> somewhat, but improves safety.

If meta data file has same permissions as trashed file, there wouldn't be
a problem. (I meant meta data for the whole trash dir here, like size info)

> No suid on trash might also mean you're not able to restore a file to a
> certain dir. untrash should then ask for an alternative location.

Yes, allowing to untrash to another dir would be a nice option, also if
original place is moved or has changed permissions. But for keeping trash
size limited, suid is needed.
Btw, the forking scheme can be used for trash too, so that suid'ed trash
only do permission and trash-dir stuff and the non suid child actually
moves the files.

Correction on my previous mail, trash-gid(775-root.group) should be
trash-gid(770-root.group) of course. Shared trash dir could have
#user+#groups+1(world writeble) entries max.

Koos