Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: net.sources.bugs
Subject: Re: What happens during an unlink(2)
Message-ID: <2759@utcsri.UUCP>
Date: Mon, 12-May-86 10:58:26 EDT
Article-I.D.: utcsri.2759
Posted: Mon May 12 10:58:26 1986
Date-Received: Wed, 14-May-86 00:45:08 EDT
References: <947@kitty.UUCP> <979@kitty.UUCP> <634@ihdev.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 22
Keywords: Disk blocks sometimes get zeroed
Summary: 

In article <634@ihdev.UUCP> pdg@ihdev.UUCP (55224-P. D. Guthrie) writes:
>In article <861@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>>Hmmmm.  Maybe there should be an option to 'rm' to cause it to zero out
>>files before unlinking them?  (like rm -e [for erase], similar to VMS's
>>DELETE/ERASE)
>>
>The trouble with this is that is really would have to be an option to
>unlink(2), which would make a lot of current software obsolete.  The
>only other way would be to have rm directly write to disk,  but there is
>too much margin for error or mass destruction here.

How about having unlink(2) look in the environment, and if it sees 'UNLINK=
zerofiles', it zeroes the storage. Relatively few calls to unlink arise from
the user typing 'rm something', so the '-e' option would be somewhat
insufficient. This way, you could get all of them without the software
obsoletion problem.

-- 
"Canabee be said2b or not2b anin tire b, if half thabee isnotabee, due2
somain chunt injury?" - Eric's Dilemma
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg