On Wed, May 24, 2006 at 02:43:38PM -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.
While we can probably make some 'versions' of files, deleted or otherwise, naturally show up in .zfs/.deleted/.version/.something directories, I wonder if we might not want an API that could let one get at all 'versions' (one version per-txg) of a file still available -- i.e., going backwards in the transaction group history, if all old blocks for a given 'version' of a file are still not reclaimed, you can then re-create the file. ACLs get interesting. For deleted files that should up in <root>/.zfs/deleted we have the problem that directory permissions in the path(s) to the file are lost, so the deleted file name really needs to be something not meaningful to humans (say, dnode/gen numbers), and any indexing needs to be per-file owner. For file versions available through some API which ACL should be checked? The current one, or the old one(s), or both/all? An API might evolve to allow for per-file snapshots/clones. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
