Design flaw in trash spec

[Alexander Larsson]

On Sat, 2007-11-24 at 01:25 +0100, David Faure wrote:
> Ouch, http://bugs.kde.org/show_bug.cgi?id=152763 is right.
> Because we create one .trashinfo file in addition to the trashed file every time,
> there is no way for the user to make room in a full partition by using "move to trash + empty trash".
> The "move to trash" operation fails because there is no room to create the .trashinfo file.
> 
> Maybe we should have use a single .trashinfo file (per trashdir) for all trashed files in that trashdir,
> so that we at least have more hopes of being able to extend it (within the limits of the allocated 
> space for it, I guess there's always a bit of padding?) rather than having to create a new file 
> for every trashed file? Not sure if that solution would be good enough though.

This sounds like a lot of work updating such a file (especially if its
large). Also, it risks data loss in the case of concurrent trashing. 

A somewhat safe update of such a file would require write to temp file
and rename over target. This would require even *more* space.

> I know how much it would suck to change the standard now, but it seems that this report
> is correct about the design flaw...

I would recomment to just fail the creation of the .trashinfo file and
still move the data file. Reading the trash can be done by reading the
data files, and if there is no related .trashinfo file we just have less
info about the file. A small feature regression for that file, but not a
huge problem really.