On Wed, May 24, 2006 at 12:18:48PM -0700, Erik Trimble wrote: > > But my point being that "undo" is appropriate at the APPLICATION level, > not the FILESYSTEM level. An application (whether Nautilus or "rm") > should have the ability to call a system library to support "undo", > which has the relevant code, but ZFS itself should have no concept of > "undo". This keeps the applications FS-agnostic, so you support "undo" > across ZFS, UFS, NFS, etc. > > So, our mythical system library (libundelete.so) should support a couple > of generic functions (say: int safe_unlink(const char *path), and void > empty_recyclebin(const char *path) which look for an ENV variable to > determine if they should recycle or should delete, as appropriate) for > applications to call, and then the library code has to support > implementing this on various FSes. > > Maybe, MAYBE, after we implement a generic system library call to > support "undo" across all (reasonable) FSes, we consider putting in > "undo" in the actual FS for performance reasons, so that the library can > simply call the FS libraries to do the "undo". >
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 -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
