Design flaw in trash spec

[David Faure]

On Monday 26 November 2007, Alexander Larsson wrote:
> 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.

This means that when listing the contents of the trash we would have to list 
the files/ directory first, then list info/ like now, and while doing that mark the files 
as seen, and then we have the list of orphaned files (those not referenced from info/).
Makes the implementation a bit more complex (right now I simply list info/),
but I realize that this allows to handle a case that isn't handled at the moment, where
something went wrong and a .trashinfo file is missing for any other reason (e.g. bugs :) ).

OK then.
Is someone updating the text in the spec to recommend handling the "disk full"
and "no .trashinfo" cases correctly?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).