Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!zorba!dtynan
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.unix
Subject: Re: Norton Utilities Under UNIX 386?
Keywords: Norton Utilities
Message-ID: <3646@zorba.Tynan.COM>
Date: 4 Jul 90 00:51:32 GMT
References: <3555@zorba.Tynan.COM> <3566@zorba.Tynan.COM> <3586@zorba.Tynan.COM> <3636@zorba.Tynan.COM>
Sender: dtynan@zorba.Tynan.COM
Reply-To: mips!esegue.segue.boston.ma.us!johnl (John R. Levine)
Organization: Segue Software, Cambridge MA
Lines: 29
Approved: dtynan@zorba.Tynan.COM

In article <3636@zorba.Tynan.COM> sl@van-bc.UUCP (Stuart Lynne) writes:
>This would appear to be a variation of the don't really delete it for a
>while type of programs.  Just move the file somewhere else where a daemon can
>get rid of it later at a reasonable interval. 

Quite true, although unlike the usual hack that replaces that mv and rm
commands, we've hooked the system calls in the kernel so that undelete
protection is provided to all programs without any changes to them.  In
case it's not clear, we do not modify any existing application program,
we add a kernel driver and provide a daemon and front end programs to
control the undelete system.

>What they have done is to also replace the disk size (df) program to
>subtract out the not quite deleted stuff so you know what you will have when
>the deletions are done.

We didn't change df, we hooked the system call it uses, for the same
reasons.  The daemon interfaces with the free space allocator, so if
you start to run out of space, the daemon knows about it and deletes
stuff as needed.

>All in all pretty trivial concepts.

Agreed, but it was a decidedly non-trivial amount of work to implement.

-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
Marlon Brando and Doris Day were born on the same day.