Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What exactly happens when an application deletes a file?

Is there any way to control this behavior? Basically I want to shred instead of rm in all cases, but of course applications do not make calls to rm, I am guessing they interact directly with the kernel?? Would I have to modify the kernel to implement this feature?

share|improve this question
Deleting a file ends up in the kernel's unlink system call (man 2 unlink). When you try to intercept that one, you need to watch out for specials (link count, file is still in use) before starting to wipe it. – ott-- Feb 26 '13 at 15:28
@ott-- you should put this as an answer below. I was just about to submit something similar to this, and then saw this. – sparticvs Feb 26 '13 at 15:43
I'd suggest that instead of writing your own fs, or attempted to do this in the C library somehow, patch an existing filesystem. E.g., maybe take a look at lwn.net/Articles/462398 – derobert Feb 26 '13 at 16:03
What are you trying to achieve? For journalling filesystems, shredding data is well nigh impossible; same for SSDs. – Deer Hunter Feb 26 '13 at 16:19
@derobert nice link, I guess I'm not the only person to have thought of this – jsj Feb 26 '13 at 16:19

Rather than trying to intercept all filesystem calls, what about encrypting the filesystem your data is stored upon? Then, all of your data gains the benefit of being securely encrypted, including that which was deleted.

share|improve this answer
Encryption is vulnerable to social engineering. But yes I get your point. – jsj Feb 26 '13 at 14:58
@trideceth12 Not encrypting is vulnerable to technical engineering. shred is useless in most circumstances. – Gilles Feb 27 '13 at 1:14
Okay from research it seems the consensus position is to encrypt the sensitive info separately, and then destroy the key when the information is to be deleted. This prevents being compelled to reveal the key. – jsj Feb 28 '13 at 0:20

You would have to go in to the C libraries as well as the filesystem kernel modules in order to catch all cases. Applications most often call a library routine that then calls a routine inside the filesystem module.

In short, the only reliable way to control this behavior is to write and use your own filesystem. I don't think you want to go there - I know I wouldn't.

share|improve this answer
Better than writing your own filesystem would be to patch an existing one, or help one of the existing attempts – derobert Feb 26 '13 at 16:12

The chattr s attribute might work on ext4-filesystems. I did not bother up until now.

I used wipe in important cases manually up until now.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.