The funny thing is, this doesn't even call fsync(2) (which is available in Node [1]). So the file contents will likely actually remain on disk for some seconds to minutes thereafter, depending on the OS, file system, and their configuration.
Rm does not permanently delete files
41–50 of 55 posts
Re: Rm does not permanently delete files
#42The 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?
> and the government had tools that could recover previously overwritten data. 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 ov…
[deleted]
Re: Rm does not permanently delete files
#43This functionality already exists in GNU coreutils, it's done by the shred(1) command. No need to install any extra third-party software, shred is already installed. Also, as another commenter already pointed out, this kind of in-place overwrite is not guaranteed to work on SSDs, and it's also not guaranteed to work on filesystems with copy-on-write semantics. If you're really concerned with this, you should be doing…
Looking at man shred, apparently one can shred stdout.
Is there any advantage to specifically disabling that?
Re: Rm does not permanently delete files
#44Neat idea, but defaulting to recursive force mode (-rf) is frankly a bit scary (and irresponsible). A great way to accidentally shoot your own foot off after you've put it through a meat grinder. I pity the fool that tries to use this programmatically with a unset or null var, eg. skrub /$imfucked
If you're going to do it in a script you'll need to set those flags anyway, won't you?
Re: Rm does not permanently delete files
#45This functionality already exists in GNU coreutils, it's done by the shred(1) command. No need to install any extra third-party software, shred is already installed. Also, as another commenter already pointed out, this kind of in-place overwrite is not guaranteed to work on SSDs, and it's also not guaranteed to work on filesystems with copy-on-write semantics. If you're really concerned with this, you should be doing…
Looking at man shred, apparently one can shred stdout.
Why not? One can shred any file descriptor. :-)
I bet one could even shred a network socket.
Re: Rm does not permanently delete files
#46The 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?
Do you remember the dd challenge where they offered money to any company that could recover a drive that had been zeroed over once with dd? Nobody ever took it.
Re: Rm does not permanently delete files
#47When you decided to write this in JavaScript you should have thought if you should instead of if you could. ;P
We are JavaScript. We are the Collective. You will be assimilated. Resistance is futile.
Re: Rm does not permanently delete files
#48The 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?
Unlikely, because while hard drives use magnetic storage (where a few magnetic domains may still point in the direction of the previous magnetization, SSDs store bits in discrete logic gates - meaning that even if there is a trace, the chip would need to be disassembled and the gates examined with an electron microscope one-at-a-time. Furthermore, it's less likely that data can survive a single rewrite, given the mec…
This is all irrelevant because there is no way to have a sector on SSD erased for sure. Overwriting relocates, TRIM marks for future deletion, Secure Erase has the unpleasant side-effect of nuking all data and, as typically implemented, also doesn't remove data but only changes internal encryption keys.
Re: Rm does not permanently delete files
#49`srm` works great.
Re: Rm does not permanently delete files
#50The funny thing is, this doesn't even call fsync(2) (which is available in Node [1]). So the file contents will likely actually remain on disk for some seconds to minutes thereafter, depending on the OS, file system, and their configuration. [1] https://nodejs.org/api/fs.html#fs_fs_fsync_fd_callback
Or years if the OS crashes afterwards.
I also wonder what happens if the file is deleted before the zeros are flushed. Is there some implicit flush, triggered by metadata changes, which saves the day? No idea.