Saturday, May 18, 2019

Re: ffs undelete was: Re: single user question

On May 18, 2019 4:08 AM, Solène Rapenne <solene@perso.pw> wrote:
>
> Le 2019-05-17 22:47, Edgar Pettijohn a écrit :
> > On May 17, 2019 3:14 PM, gwes <gwes@oat.com> wrote:
> >>
> >>
> >>
> >> On 5/17/19 2:34 PM, Nathan Hartman wrote:
> >> > On Fri, May 17, 2019 at 12:28 PM ropers <ropers@gmail.com> wrote:
> >> >
> >> >
> >> > In the history of the (Berkeley) Fast File System, has there ever been
> >> > an attempt to implement DOS-like undelete for FFS/UFS?
> >> >
> >> > Maybe that could work for "normal delete" while making available a separate
> >> > "secure delete" that cannot be un-deleted and furthermore overwrites the
> >> > deleted data with random garbage. Administrators could optionally force the
> >> > secure overwrite delete.
> >> >
> >> I haven't looked at e.g. zfs in a long time.
> >>
> >> A journal-like system which held the deleted/overwritten files
> >> or a system of renaming wouldn't be *that* hard to instantiate
> >> There are some problems:
> >> (a) denial of service by writing and deleting huge [numbers, size]
> >> files.
> >> (b) retention policy - under what conditions does the system
> >>   guarantee existence of backup files?
> >> (c) versioning - If I create & delete 'a' six times, how many copies
> >> are
> >> held.
> >> (d) cost of undelete operation - it's not clear how to make
> >>      that efficient.
> >>
> >> I'm sure people can find more.
> >>
> >> A test version substituting a new open(2) and unlink(2) in libc would
> >> be
> >> easy to make.
> >>
> >> geoff steckel
> >>
> >
> > I'm thinking something like a trashcan. Where rm(1) actually just
> > moves the files to some predetermined location then on shutdown all
> > files older than some configureable date are actually unlinked.
> >
> > Edgar
>
> you can write a shell script to move given parameters into a special
> folder
> and make alias rm="that_script"
> and a rc script which empty this folder at boot/shutdown.
>

Im thinking putting the script in ~/bin/rm may be better long term. Either way just shows there isn't a pressing need to make code changes for what a couple lines of shell scripts can do fairly easily.

Edgar

No comments:

Post a Comment