Scot L. Harris wrote:
On Wed, 2005-07-27 at 13:10, Mike McCarty wrote:I am familiar with these, but the primary objection to what he wrote is that this is a journalled file system. IOW, the writes take place to a separate location and then are committed.So the real question is, how can you flush the journalled information prior to running the shred utility? And where is the journalled information stored prior to being committed?
Not entirely. One issue is that if I overwrite the file, the location which contains the original data is *not* the place the overwrite is done to. The journaled info is another, but valid, issue.
Another question is, is the customer requiring a DOD level of deletion or is a standard rm sufficient? Realizing that with significant effortthat some of the data may be recoverable?
What exactly they mean by "permanently eradicate" is not specified, but I seriously doubt DOD standards. I've been requested to e-mail them updates simply by using PKZIP with an encryption key. That's hardly what one would call "secure". OTOH, they do specify that backups containing that information be "destroyed". I asked what that meant, and was told "just break the CDs".
I suspect that if you make a best effort at deleting all project files and disposing of any backups of these files they are not going to be concerned with the possible use of forensic recover techniques to get portions of those files back.
I suspect you are right. I don't foresee any real problem. But I'd
like to comply with the contract in the most comprehensive way
possible. I'm not so concerned with them complaining, as I am with
my own ethical standards. I signed that contract, and I want to be
a man of my word.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
