In a project I am doing I want to give users the option of 'securely' deleting a file - as in, overwriting it with random bits or 0's. Is there an easy-ish way of doing this in C#.NET? And how effective would it be?
-
1possible duplicate of [Shredding files in .NET](http://stackoverflow.com/questions/1046635/shredding-files-in-net) – Darin Dimitrov Nov 10 '10 at 18:34
-
You completely missed the point of my answer, there is no way to ensure that the data you are trying to write to a file will actually occupy the same location on disk as the data it is replacing, so you can't do what you are asking. – mikerobi Nov 10 '10 at 18:59
-
Do you want to securely delete the contents, or do you want to overwrite it with random bits? They are not the same. Just overwriting the file is not going to do what you want, I think. – Steve Townsend Nov 10 '10 at 20:11
-
@mikerobi - this is extremely hard (esp. from C#), but not impossible. – Steve Townsend Nov 11 '10 at 00:51
-
possible duplicate of [C# - Deleting a file permanently ](http://stackoverflow.com/questions/3330427/c-deleting-a-file-permanently) – Ben Voigt Dec 30 '10 at 06:36
5 Answers
You could invoke sysinternals SDelete to do this for you. This uses the defragmentation API to handle all those tricky edge cases.
Using the defragmentation API, SDelete can determine precisely which clusters on a disk are occupied by data belonging to compressed, sparse and encrypted files.
If you want to repackage that logic in a more convenient form, the API is described here.

- 53,498
- 9
- 91
- 140
You can't securely delete a file on a journaling filesystem. The only non-journaling system still in heavy use is fat32. On any other system, the only way to securely delete is to shred the entire hard drive.
EDIT
The reason secure delete doesn't work, is that that data used to overwrite a file might not be stored in the same location as the data it is overwriting.
It seems Microsoft does provide a secure delete tool, but it does not appear to be something that you can use as a drop in replacement.
The only good way to prevent deleted file recover, short of shredding the disk, would be to encrypt the file before it is written to disk.

- 20,527
- 5
- 46
- 42
-
Thanks for the reply, I've rephrased a question a little bit. It doesn't matter if the file is _totally_ erased, all that matters is that I use similar methods to a bog standard file erase program – Chris Nov 10 '10 at 18:35
-
-
if the file is, say, 100mb in size, it is completely impractical to keep the whole encrypted and original files in RAM... – DividedByZero Aug 26 '14 at 18:50
It wouldn't be secure at all. Instead you may wish to look at alternative solutions like encryption.
One solution would be to encrypt the contents of the data file. A new key would be used each time the file is updated. When you want to "securely delete" the data simply "lose" the encryption key and delete the file. The file will still be on the disk physically but without the encryption key recovery would be impossible.
Here is more detailed explanation as to why "secure" overwrites of files is poor security:
Without a low level tool (outside of .net runtime) you have no access to the physical disk location. Take a filestream on NTFS, when you "open a file for write access" you have no guarantee that the "updated" copy (in this case random 101010 version) will be stored in the same place (thus overwriting the original file). In fact most of the time this is what happens:
1) File x.dat is stored starting at cluster 8493489 2) You open file x.dat for write access. What is returned to you by the OS is merely a pointer to the file stream abstracted by not just the OS but the underlying file system and device drivers (hardware RAID for example) and sometimes the physical disk itself (SSD). You update the contents of the file with random 1 & 0s and close the filestream.
3) The OS likely may (and likely will) write the new file to another cluster (say cluster 4384939). It will then merely update the MFT indicating file x is now stored at 4384939.
To the end user it looks like only one copy of the file exists and it now has random data in it however the original data still exists on the disk.
Instead you should consider encrypting the contents of the file with a different key each time file is saved. When the user wants the file "deleted" delete the key and file. The physical file may remain but without encryption key recovery would be impossible.

- 4,541
- 2
- 31
- 47
-
the file can't be recovered without the key so it's basically lost right? wrong. the key is ALSO recoverable the same way the file would have unless one knows exactly what he's doing – DividedByZero Aug 26 '14 at 18:47
I'd first try simply to open the file and overwrite its contents as I would normally do it. Pretty trivial in C#, I won't even bother to write it. However I don't know how secure that would be. For one thing, I'm quite certain it would not work on flash drives and SSD's that use sophisticated algorithms to provide wear leveling. I don't know what would work there, perhaps it would need to be done on driver level, perhaps it would be impossible at all. On normal drives I just don't know what Windows would do. Perhaps it would retain old data as well.

- 104,512
- 87
- 279
- 422
-
1It won't work on any journaling filesytem, regardless of the drive type (see my answer for an explanation). – mikerobi Nov 10 '10 at 18:42
-
@mikerobi - I know, but aside from that - this is the next best thing. At least the typical undelete utilities will be fooled. – Vilx- Nov 10 '10 at 22:17