Unifying ~/Desktop

[Havoc Pennington]

Thomas Zander <zander at planescape.com> writes:
> Where does it create these dirs? In the root of the filesystem(s); then how does 
> it handle devices where the root is read-only?  Or does it maintain a list of
> trash dirs per user?  I see lots of potention flaws in this design, hope you covered
> them :)
> Any docs on the subject?

Yeah the cases are all covered, I don't know of docs other than the
code or the list archives.

I didn't follow the decision too closely but AFAIK the reason for the
design is to be able to move to trash with a rename() instead of a
copy. This avoids disk space issues and makes move-to-trash an atomic
operation (and faster). Also, it means that the trash on a shared
filesystem is shared. So if I throw something away on a workgroup
server anyone in the workgroup can remove it from the trash. Hmm, also
it means that for removable media the trash travels with the media, so
if I throw something away on a floppy it stays on the floppy instead
of copying to/from the hard drive. There may be other reasons.

The trash goes on the root of the filesystem if the root is writable
and otherwise falls back to ~/.Trash, IIRC.

I believe there is no need to keep a list of trash dirs per user since
the trash is located via a fixed algorithm. Nautilus just looks at the
root of all mounted filesystems plus ~/.Trash and merges those into
the list of files in the virtual trash:/// location.
 
> Be aware that in KDE you can name your trash dir anything you want (just rename
> the icon, overruling the translations).
> The icon is defined in the <your_trash_dir>/.directory
> but the fact that we allow a different options-menu (including empty-trash) for
> the trashcan exists since we register in the kdeglobals file the full-path to the
> trash dir.

Is this preference useful? ;-)

I think we can hack around it somehow.

Havoc