Ummmm. Remind me why we should support "undo" (or, more aptly named, "safe delete") in ZFS?
Isn't this an application feature, not a filesystem feature? I would expect something like this behavior when using Nautilus, but certainly not when using "rm". That is, maybe there should be a library which has a "safe delete" system call for use by applications, and has code specific to the various filesystems to implement the feature, but I can't really see the point in implementing "safe delete" at the filesystem level. It screws with too many long-standing assumptions. If you want to do avoid a namespace collision, you'll probably have to implement the "recycle bin" as a DB and file collection. Move the file being deleted over to /your_pool/your_fs/.zfs/deleted/, and rename it by a unique ID (whatever the ZFS equivalent of Inodes is, for example). Keep the ACL/permissions on the file, but put the complete pathname (relative to the root of the filesystem) [and, maybe something like create_date as well] in a hashtable with the ID key. For directories, you might need something a little more fancy in the DB (like keeping the full ACL/perm metadata there). Thus, you'd end up with something like: % ls /your_pool/your_fs/.zfs/deleted/ files.db dirs.db 10021238 01924132 13243542 And, once again, I've totally forgotten where the ZFS bug list lives. Pointers, please? -- Erik Trimble Java System Support Mailstop: usca14-102 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
