Le 2019-05-17 22:47, Edgar Pettijohn a écrit :
On May 17, 2019 3:14 PM, gwes <g...@oat.com> wrote:
On 5/17/19 2:34 PM, Nathan Hartman wrote:
> On Fri, May 17, 2019 at 12:28 PM ropers <rop...@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.
