Dear xdg list, I've considered implementing the freedesktop.org trash specification [1] for Nautilus, but I'm not willing to do this in the spec's current shape.
I don't understand why it was decided to use .desktop files for the trash specification, and use a pretty complex hierarchy compared with the legacy .Trash handling. We basically want two pieces of information per trashed file/folder: Its deletion date, and its original storage path. Why couldn't we just use extended attributes for storing these, and instead require a two-directory layout, which requires extra files for each trash entry? A typical trash usage includes sorting of trashed entries by deletion date, so we'd have to read this date from the corresponding info files for each trash entry before we're able to fully display its properties: We readdir() .Trash/files, and then for each entry .Trash/files/myfileN open() and read() .Trash/info/myfileN, and parse its contents. It may be quite expensive when you have many trashes for multiple volumes, and adds implementation complexity. If we'd stuff all the info/ contents into a cache file this would definitly offer better performance, but we'd have to extract the info from the info/ files. While INI file parsing isn't really a problem I think we should still avoid it, when we have file-system facilities for storing key/value information. Note that FAT32 (popular USB stick / removable storage format) does not offer extended attributes, but it has other drawbacks anyway, and taken its use-case we could just restore to the volume toplevel directory for removable volumes and not save the deletion date at all. As USB stick capacity grows, people are more likely to use more advanced file systems like NTFS and ext*, which support extended attributes. Using FAT32 for permanent storage is not recommended, and it's not used on a daily basis anymore, so we shouldn't consider that an argument against extended attributes. [1] http://www.ramendik.ru/docs/trashspec.html -- Christian Neumair <[EMAIL PROTECTED]> _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
