Super User is a question and answer site for computer enthusiasts and power users. 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

Specifically, does type nul > somefile overwrite the entire file on disk? I saw a batch script website recommend generating an FTP script on the fly and then "securely" erasing it with the command in title. Is there any merit to this?

share|improve this question
up vote 5 down vote accepted

What does “type nul > somefile” do to “somefile” in Windows?

  1. First, somefile is opened for writing – this automatically causes the file to be truncated to 0 bytes. The data still remains on disk, just marked as "free" in the bitmap

  2. Then the contents of nul are written to somefile – in this case, exactly zero bytes, since you cannot read anything from nul. The old data is not overwritten.

  3. The file is closed.

I saw a batch script website recommend generating an FTP script on the fly and then "securely" erasing it with the command in title. Is there any merit to this?

It's not any more "secure" than del somefile. It doesn't even remove the data from disk.

To erase a file securely, use a wipe utility such as sdelete or Eraser. Although, is a FTP script actually worth secure-wiping?

share|improve this answer
"Is a FTP script actually worth secure-wiping" - Well, it exposes a password in plaintext on a remote machine. – wes Apr 12 '11 at 15:37
@wes: If you cannot ensure physical and OS security of the machine to prevent recovery of said script, then you equally cannot ensure that the FTP traffic is not being sniffed... But a few suggestions. Switch to a more secure protocol - SFTP or at least FTP/TLS. In addition, make a separate directory for the password-containing file (either the script, or the client's config file) and enable the EFS encryption for it. All new files inside would be automatically encrypted at OS level. Both of the protocols support public key authentication as an alternative, too. – grawity Apr 12 '11 at 16:48
And note that on SSDs all bets are off; currently you simply cannot erase those as the actual bits on the device are decoupled by at least one abstraction layer from the OS. – Joey Apr 13 '11 at 4:52
Therefore the only solution is not to store plaintext credentials to disk in the first place. – grawity Apr 13 '11 at 5:44

It 'might' overwrite the file with zeros, but even if it did, that's hardly a secure erase. You would be better off using SDelete for this if you can.

share|improve this answer

Deleting a file will not prevent third party utilities from un-deleting it again, however you can turn any file into a zero-byte file to destroy the file allocation chain like this:

TYPE nul > C:\examples\MyFile.txt

DEL C:\examples\MyFile.txt

Source half way down the page

share|improve this answer
How does that differ from only DELeting the file? In either case the OS is going to eventually overwrite that space on disk, yes? – wes Apr 12 '11 at 15:43
Eventually, yes but when, next year? No way to know when. – Moab Apr 12 '11 at 19:03
My point in asking being to determine what immediate/beneficial effects "destroying the file allocation chain" has in comparison to simply deleting the file. – wes Apr 13 '11 at 14:04
Immediate destruction of the data (file) so you cannot use software to recover it like you can when you simply delete it, at least that is my take. – Moab Apr 13 '11 at 15:07

You must log in to answer this question.

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