Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rm does not permanently delete files

medium.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Rm does not permanently delete files

#51

Post by brudgers »

wiredfool wrote: post #9
throwaway7767 wrote: post #6

This 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.

"Shredding stdout" sounds like the highest complement for a command line utility.

Re: Rm does not permanently delete files

#52

Post by pritambaral »

aavotins wrote: post #15

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

> Plus the -P flag is available on both GNU ...

    [pritam@PritePad ~]$ cat /etc/lsb-release 
    LSB_VERSION=1.4
    DISTRIB_ID=Arch
    DISTRIB_RELEASE=rolling
    DISTRIB_DESCRIPTION="Arch Linux"
    [pritam@PritePad ~]$ touch t
    [pritam@PritePad ~]$ rm -P t
    rm: invalid option -- 'P'
    Try 'rm --help' for more information.
`man rm` does suggest looking at shred(1) in the SEE ALSO section

Re: Rm does not permanently delete files

#53

Post by pritambaral »

maze-le wrote: post #24
noja wrote: post #17

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.

The file, yes, but not the file contents. Worst of all, if you opened the file recently with any process, there is a pretty good chance that the file-descriptor can be found in: /proc/ somewhere. 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.

You are correct that the file contents may remain in memory.

Neither this tool nor GNU shred nor BSD `rm -P` can do anything about it.

Re: Rm does not permanently delete files

#54

Post by dTal »

wiredfool wrote: post #9
throwaway7767 wrote: post #6

This 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.

And yet it doesn't "work":

  dtal@reepicheep:~$ cat /dev/urandom | shred -
  shred: -: invalid file type

Re: Rm does not permanently delete files

#55

Post by colanderman »

dTal wrote: post #54
wiredfool wrote: post #9

Earlier quoted context omitted.

Looking at man shred, apparently one can shred stdout.

And yet it doesn't "work": dtal@reepicheep:~$ cat /dev/urandom | shred - shred: -: invalid file type

Your command points stdin to the output of some random command. Even if you actually redirected stdout (pipe to cat, not from), it still wouldn't work, because cat's stdin isn't a file.

You need to point stdout to an actual file, like this:

    shred > /my/secret/file.txt
Why would you do this? At the end of a long batch of commands that all write to some temporary file opened on stdout. Not uncommon in shell-land.
Post reply on HN