|-n||Erase the file, but do not delete it. This is provided for the sake of embedding applications which want to do deletions themselves. For example, Dan Bernsteins serialmail package is compatible with fwipe0. You can use it to erase the contents of a maildir with the command maildirserial dir prefix fwipe0 -n.|
|-ttimes||Overwrite the file times times. Default is 5.|
Experimental: introduce a delay factor out of niceness to other users. Since
overwriting a file is very I/O intensive, fwipe can make the system fairly
unresponsive to interactive users. Lowering the priority using
nice is a good idea, but it doesnt help responsiveness much--most of the work
is being done by the
bdflush daemon, which runs at kernel priority. The
-sSlowness option adds a periodic pause during operation, which allows lowered
priority to actually kick in and schedule other tasks. The argument
can be any number between 1 and 32, with 1 giving the largest
slowdown. When "slowness" is turned on, fwipe0 sleeps after writing
2^slowness blocks. This is an embarrassment of variety, I realize:
slowness below 11 or 12 results in ridiculously long execution times, and values
above 16 or 17 seem to eliminate most of the benefit of the feature (but
might still be useful in conjunction with higher
Note that fwipe0 does not monkey with its own priority; you still have to use nice to lower the priority of fwipe0. Please experiment with different slowness settings and different nice values, and let the author know how well this feature is working for you. Something around nice -10 fwipe0 -s15 is recommended as a starting point.
The duration of the sleep starts at 1 second, and then gradually increases using the same "quadratic backoff" scheme as qmail-send. The rationale is that small file wipes are not affected much by this backoff, but large files on the other hand take a long time to wipe anyway--so who cares if a 1GB wipe takes 2 hours or 4 hours? The wait is determined by counting the number of times fwipe0 invokes sleep(). The sleep duration is the largest perfect square <= that count. So the first three sleeps are 1 second long; the next five are 4 seconds long; the next seven are 9 seconds long, etc. The number of blocks written between sleeps is constant and is determined by the -sslowness argument as explained above.
At the moment, fwipe0 always returns a "temporary error" status on failure. That may change, if I ever decide which errors are temporary, and which are permanent.
The "slowness" feature is highly experimental--it has no impact on the security or reliability of fwipe, but I havent the foggiest what settings are to be recommended for various uses. Please give me your feedback!
Also, there is a race condition when fwipe0 decides whether a file has grown before deleting it. It is possible for someone to append data to a file after fwipe0 has decided to delete it, and before it is deleted. This might result in some information leaking to disk without being wiped.
Users of fwipe0 should generally make sure that they control the files they are wiping, and that they arent running anything which might keep appending to the file.
Admins might want to occasionally fill the disk with data, and then run fwipe0, to erase information which was insecurely deleted (either by rm or through the fwipe0 weaknesses already mentioned). Also, dont forget degaussing, and vats of molten steel.
Copyright (c) 2000, Len Budney. All rights reserved. fwipe0 is made available under the terms of the BSD license.