Hi eugenet, Some interesting ideas here. Believe it or not, the trash mechanism in Gnome used to work in a manner very similar to what you describe (minus the zfs specific bits). Trash used to be a move operation to a .Trash-<username> at the toplevel of the traditional filesystem on which the file was stored. For example:
/export/home/eugenet/Docs/core would move to /export/home/eugenet/.Trash/core /export/home/share/foo/bar/some.file on filesystem /export/home/share would be moved to /export/home/share/.Trash-eugenet/some.file (assuming the location was writable by user eugenet). This approach was nice in that it reduced copying of data from one filesystem to another. However, it had some severe performance and reliability consequences on large shared servers such as Sunray and systems with a lot of network automounts. Because trash was distributed, to present a unified view of Trash in nautilus, it had to search all mountpoints for trash folders. This triggered potentially huge numbers of undesired automounts to get mounted and if one of them was an NFS hard mount (the default) that was unresponsive it would block the entire nautilus process. This caused major pain for Sunray users in particular and we had to patch nautilus to use just the user's home directory for Trash storage which is the way Trash now works in Gnome today by default. We don't want to reintroduce these problems :) Your idea does make me think however: in some ways the traditional notion of a Trash folder has become redundant when you have snapshots. They basically provide the same thing - a way to retrieve files after you have deleted them. Although there is much less searching to do in the Trash folder compared to searching through many snapshots that present the entire filesystem contents and many versions of the same file. Just my ?0.02 Thanks, Niall -- This message posted from opensolaris.org
