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.
No comments:
Post a Comment