21–30 of 55 posts
Author himself stated that rm has a -P flag, that actually does the same thing more correctly and more securely: >Files are overwritten three times, first with the byte pattern 0xff, then 0x00, and then 0xff again, before they are deleted. Plus the -P flag is available on both GNU and BSD versions of rm. Somehow I fail to see the user-friendliness factor. Edit: formatting
Is this still true with SSDs?
This is the type of program that should be written in C, not in Javascript with 9 different dependencies...
True. But no harm in getting it off the ground quickly before optimising. Git was written in Perl originally, and ported bit by bit to C. I think this shows it can be a good way to work -- prototype quickly, then optimise.
When using the terminal command rm (or DEL on Windows), files are not actually removed. Yes they are. As a user, I see a file, type rm file, then it is gone. The file has been removed. Yes those parts of that file are possibly recoverable back into the original file, even without much work, but the file has been removed.
/proc/
And with that in mind you can use a combination of lsof, grep, sed or any other tool to still read the file as it was.
The old hard-drive lore was that files may still be recoverable until the contents have been written 7 times - and the government had tools that could recover previously overwritten data. Is this still true with SSDs?
This is the type of program that should be written in C, not in Javascript with 9 different dependencies...
True. But no harm in getting it off the ground quickly before optimising. Git was written in Perl originally, and ported bit by bit to C. I think this shows it can be a good way to work -- prototype quickly, then optimise.
I pity the fool that tries to use this programmatically with a unset or null var, eg.
skrub /$imfuckedEarlier quoted context omitted.
True. But no harm in getting it off the ground quickly before optimising. Git was written in Perl originally, and ported bit by bit to C. I think this shows it can be a good way to work -- prototype quickly, then optimise.
This. You can bicker all day long about the "correct" language to write something in but at the end of that long day of going back and forth nothing actually got written. Better to go with what you know and prototype then weigh the benefits of rewriting/refactoring it in another language/toolchain.
The old hard-drive lore was that files may still be recoverable until the contents have been written 7 times - and the government had tools that could recover previously overwritten data. Is this still true with SSDs?
That wasn't true. But, since we can't prove it's not true precaution says you should over-write drives a few times with pseudo random data.
SSDs are a bit more worrying because end users don't have full control.
But with physical drives or SSDs if the data is that important you should be looking at physical destruction, rather than just over writing.