[EMAIL PROTECTED] wrote on 02/20/2007 08:10:59 AM:

> On Tue, Feb 20, 2007 at 02:07:41PM +0100, Robert Milkowski wrote:
> > Hello Jeremy,
> >
> > Monday, February 19, 2007, 1:58:18 PM, you wrote:
> >
> > >> Something similar was proposed here before and IIRC someone even has
a
> > >> working implementation. I don't know what happened to it.
> >
> > JT> That would be me. AFAIK, no one really wanted it.  The problem that
it
> > JT> solves can be solved by putting snapshots in a cronjob.
> >
> > Not exactly the same.
> >
> > But if people really do not want it...
>
> There's a fundamental problem with an undelete facility.
>
>    $ echo > FILE
>    $ undelete FILE
>    cannot undelete FILE: file exists


Why the assumption that an undelete command would be brain dead -- this IS
Unix. =) Seems like a low bar issue,  if file exists and undelete has the
file with the same filename available to restore,  error and have the user
-f (Force), -n <filename>  (reName the restored file) ...
Even this:

$ echo "one" > FILE
$ rm FILE
$ echo "two" > FILE
$ rm FILE
$ echo "three" > FILE
$ undelete -n FILE.restored FILE
ERMVERSIONS:  FILE has multiple deleted versions. Try undelete -l FILE to
get the list of available versions, or -f to Force the operation restoring
the latest version.

Should be doable.  I actually have a perl script that does exactly this for
a given file or path based on available snap data (not per filesystem
change snap) -- it does get a little hairy on a fs with many thousands of
snaps as there is some overhead in stat()ing paths under all of those .zfs
mounts.

-Wade

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to