0

I am trying to delete a file in linux, (Ubuntu 20.04). As per my understanding, when we delete a file, the inode and directory entry structures are modified first and the file is actually deleted at a later time. This is one of the reasons why the file can be recovered by different tools later.

I want to delete a file and know that it has been physically deleted from the disk. There should be no way that I can retrieve it at any point of time.

nishad kamdar
  • 73
  • 6
  • `shred` is your friend – Panki Jul 07 '20 at 15:13
  • 1
    @Panki not on an SSD it's not. Wear levelling may mean new sectors get allocated rather than old ones being overwritten – roaima Jul 07 '20 at 15:18
  • Looking at the "caution" section in `man shred`, it also doesn't promise to work with journaling filesystems, which is… pretty much all of them, these days? I guess you could delete the file and then `dd if=/dev/random of=fillthedisk; rm fillthedist` which should fill most space available to files, likely including the old file contents, with randomness. – Ulrich Schwarz Jul 07 '20 at 15:47
  • This can be done with [BleachBit](https://docs.bleachbit.org/doc/command-line-interface.html#:~:text=Linux%20Running%20bleachbit%20%28which%20is%20in%20the%20path%29,generally%20not%20available%20over%20SSH%20or%20in%20cron%29.). *$ bleachbit --shred /path/to/file* – KGIII Jul 07 '20 at 16:33
  • Rather than shred the whole empty area of the disk, you might just find the block count of the file and use `dd -i /dev/zero` to kill the data `before` you rm it. Not sure why random junk is any harder to recover the data from than zeroes. Special care may be needed for huge sparse files. – Paul_Pedant Jul 07 '20 at 16:57
  • You'll find several Q/As about this topic here on U&L. For instance, these look relating: https://unix.stackexchange.com/a/63424/315749, https://unix.stackexchange.com/a/245999/315749 – fra-san Jul 07 '20 at 17:39

0 Answers0