[15958] in Athena Bugs
Re: saferm
daemon@ATHENA.MIT.EDU (Thomas Bushnell, n/BSG)
Thu May 28 15:43:53 1998
Date: Thu, 28 May 1998 15:43:50 -0400
From: tb@MIT.EDU (Thomas Bushnell, n/BSG)
To: cfields@MIT.EDU
Cc: kcr@MIT.EDU, bugs@MIT.EDU
In-Reply-To: Craig Fields's message of Thu, 28 May 1998 15:40:08 -0400
<199805281940.PAA07817@mad-scientist.MIT.EDU>
Date: Thu, 28 May 1998 15:40:08 -0400
From: Craig Fields <cfields@MIT.EDU>
> (I found two other problems in the code as well; it should do an fsync
> after the zeroing, and it should do the zeroing after the unlink.)
Why is close is not sufficient?
Because the zeroing might happen arbitrarily far along in the OS. The
point is so that the bits are gone from the disk when the cleanup
cycle is done. Filesystem writes are normally delayed by the kernel,
and so the bits might still be alive on the disk. If there's any
utility behind doing a zero at all.
I'm not sure of the utility of zeroing after the unlink. I imagine
that the idea is to make sure that the user doesn't write data into
the file at the last second that fails to be zeroed, but doing this is
no guarantee that that will be avoided.
That's one idea; my idea doesn't eliminate the window but it reduces
it.
But my real goal was that `saferm -z' should be as much like `saferm'
as far as user-visible effects go. The existing code is not like
that, because with `saferm -z' there's a time where the file appears
with zeroed contents.
Thomas
