> > >
> > > 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.
>
> Sorry, the name of the file isn't the problem. It's the contents of
> the file. Does truncating a file constitute deletion? How about
> replacing the contents? Or replacing part of the contents? Perhaps
> any change to the file? How far should this go? Every new line
> appended to a log file?
>
> --
> -Gary Mills- -Unix Support- -U of M Academic Computing and
Networking-
Got it, my assumption is undelete would only act on deleted files.
Truncating, changing the files data are not delete operations (unlink).
You are starting to talk about versioning at that point -- in which case
this issue becomes way more complicated. Applications may do multiple
writes to a file with the intent of one transaction, there is no way to
tell that the three or four writes leave the file in a "broken" state until
the fifth write happens, the app may be watching and handling this
transitory state and there is no shared knowledge of its current state.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
