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
