As far as I know, there is a table of files present in the hard drive that does not contain the data of each file but can point you to it.

When you delete a file, the record of it gets deleted from the file table, but the data remains on the computer.

So the question is: If you overwrite a file's data with, let's say, just using WriteFile Win API to overwrite all data with zeros, will that become unrecoverable?

  • 1
    this may answer your question security.stackexchange.com/questions/5749/…
    – elsadek
    Commented Apr 19, 2020 at 20:36
  • 4
    Does this answer your question? Overwriting hard drive to securely delete a file?
    – ThoriumBR
    Commented Apr 20, 2020 at 4:18
  • 1
    Not completely unrelated but interesting reading is "how they <<securely>> disposed of Edward Snowden laptop". It gives an idea of how complex is safe erasure. Commented Apr 20, 2020 at 9:12
  • 3
    This definitely a duplicate question, if you use the search function you will find lots of related questions. The short answer however is that there is no guarantee that the file will be completely overwritten, because there are too many layers of abstraction between your software and the hardware (caches, OS, firmware, all kinds of optimizations, etc.)
    – reed
    Commented Apr 20, 2020 at 12:38
  • 1
    I set the drive on my driveway and then drive the car over it. After which I put it on a charcoal fire and cook until done.
    – Hot Licks
    Commented Apr 20, 2020 at 18:24

5 Answers 5


Yes, most likely. However there can always be edge cases:

  • SSDs are doing wear leveling etc., and will most probably not write your zeroes to the same cells your original data was written to. How the attacker will find and access that data is another matter altogether of course.
  • On a traditional spinning HDD, the original data may exist on other sectors because the disk got defragmented. Or the OS may decide to relocate your file on write, to consolidate the file. At least OS/2 used to do that, I am not sure if current windows version still do that.
  • NTFS stores small files directly in the directory structure btree, that may lead to your data getting copied around the disk.
  • the OS may have created a system snapshot, etc.
  • 3
    I see, so it's not very reliable. Thanks for your answer!
    – GuestBro
    Commented Apr 19, 2020 at 21:18
  • 1
    @GuestBro overwriting disks is much more reliable, though that's not available for alot of cases.
    – Legorooj
    Commented Apr 20, 2020 at 8:38
  • 10
    SSD (can) use the Sanitize command which guarantees erasure
    – Rsf
    Commented Apr 20, 2020 at 9:42
  • 4
    Great answer. However, the summary contradicts it - it is not "most likely", that's at most a "probably" :-).
    – sleske
    Commented Apr 20, 2020 at 13:00
  • 4
    I wouldn't really classify SSD wear-leveling as an "edge case". If your system has an SSD or other non-magnetic storage, odds are good the data will persist after basic overwrite at the OS level.
    – MooseBoys
    Commented Apr 20, 2020 at 18:02

So the question is: If you overwrite a file's data with, let's say, just using WriteFile Win API to overwrite all data with zeros, will that become unrecoverable?

Don't use the WIN API WriteFile to try and securely delete. Instead use a secure delete tool like SysInternals sdelete.

If you just use WriteFile the operating system/file system has the option of writing the new data (e.g., a bunch of null bytes or whatever) to a new block on the disk and then updating the master file table to point to the new block not the old block. You will not be assured that you have overwritten the original file data (unless you use WriteFile to, say, write a file as large as the entire disk).

  • Does sdelete understand solid state drives, thin provisioned media, etc.? The web page seems to imply that it only works (properly) with directly attached spinning rust. Commented Apr 22, 2020 at 22:53
  • No, I don't think it understands solid state vs any other underlying drive. So, for example, it probably doesn't know about stuff that the solid state drive might be doing like wear leveling or other solid state devices specifics that could potentially preserve data. But it is definitely a lot better than using WriteFile.
    – hft
    Commented Apr 23, 2020 at 0:34

One way to dispose of a file in a 100% reliable manner is to keep it on a separate HDD partition you can purge, or, better yet, on a separate medium you can afford to destroy.

If that's not practical, a good compromise is to make sure the file is only stored encrypted. When you need to "destroy" it, all you have to do is to forget the key. You don't have to care about edge cases leading to the file not being fully overwritten.

The next less secure alternative is to use a file shredder that you trust. If it's implemented correctly, it will track every sector on the disk associated with the file and overwrite it. Of course, it will not be able to destroy any copies of data that you, your OS, or your storage controller have made that it doesn't know about (think temporary files, swap, disk defragmentation, etc.). In general, it only makes sense to pay for a tool that was subject to a security audit.

Then comes your idea of simply overwriting the file. It's not 100% secure, but it will for sure make the data unrecoverable using off-the-shelf undelete tools. That's actually sufficient in many practical situations.


Effectively, yes, overwriting the blocks used by a file will make it unrecoverable.

This can be done using sdelete on Windows, or shred on Linux.


In order to do that securely you have to know what you are doing and the task can be quite hard depending on the OS, filesystem type, filesystem options (journaling, compression, self-defragmentation, redundancy, TRIM support), existence of automatic backup, the type of storage media (SSD, honest-to-god HDD, HDD w/ SMR), the need (or lack thereof) of plausible deniability...

and most importantly, the abilities and the motivation of the potential adverse actors.

See the links in the first comments.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .