Cool -
I can see my old fav's from Netware 3.12 making a comeback.
It was always great to be able to salvage things from a disk that
someone did not mean to kill. :)
ah - salvage - my old friend...
Does this also usher in the return of purge too? :)
Nathan.
Erik Trimble wrote:
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.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
