On Wed, 2006-05-24 at 14:43 -0700, Eric Schrock wrote: > No, this is not the point of this RFE. We are not trying to implement a > wide-ranging subsystem that understands how to manage semantically valid > undo points. This would never, ever, be supported by any significant > number of applications, and is probably impossible at the filesystem > level. > > The point is rather to provide "undelete", which will account for 99% of > all the times that someone would want to have 'undo'. This is a vastly > simpler problem, and probably more useful. Feel free to think of it as > 'undelete' instead of 'undo' if it makes things easier. > > - Eric
Sorry, semantics on my part. I mean "undelete", in a manner identical to having the Recycling Bin functionality of Nautilus or Windows Explorer. That is, when you "delete" a file, it is actually moved aside to some hidden place, where it can be recovered easily by another command. All my arguments are concerning this kind of functionality, which I'm trying to say belongs up in the app. Otherwise, it gets _very_ confusing. Let's say that you implement "undelete" in ZFS, which, in order to work, has to (a) be an enabled attribute of the ZFS pool or filesystem, and (B) uses some sort of an ENV var to indicate that a given user's tools will do "undelete" instead of permanent remove. Now, you end up with a situation where behavior of an app varies significantly across filesystem boundaries, which are _supposed_ to be invisible to the end-user. That is, the behavior of "rm" varies according to where in the filesystem tree I sit. Additionally, it doesn't allow for variation; that is, deleting a file via "rm" and "nautilus" does the exact same thing, even if I wanted "rm" to actually remove the file and not just send it to the recycle bin. Rather, I would submit that for better consistency, having a new global libundelete.so (containing a modified "unlink") which implements "undelete" in a FS-agnostic way is better. You get the feature across all Filesystem Types that way, and it's portable. It would also allow apps to decide if they want to support "undelete" or vanilla "unlink" on an app-by-app basis. The apps would have to link against the new libundelete.so to get the functionality, which I think is reasonable. -- 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
