7

Is there a built-in command in Windows 7 or higher to fill a file with zero / NULL bytes?

The processing should happen in-place (i.e. it should modify the actual disk sectors / bytes of the file), and not create a new file.

Something like: 

zero c:\temp\*.*

or

zero hello.bin

that would do this:

Before: hello.bin (500 MB)
5D 1A CB FF FF C0 ... AA CD 0F FF


After: hello.bin (500 MB)
00 00 00 00 00 00 ... 00 00 00 00

If there's nothing built-in for this, what other solutions exist? Or would I have to do it in C?

I say Reinstate Monica
  • 26,651
Basj
  • 2,143

3 Answers3

9

Is there a built-in command in Windows to fill a file with zero / NULL bytes?

Yes. You can use fsutil for this:

> fsutil file setzerodata /?
Usage : fsutil file setzerodata offset=<val> length=<val> <filename>
   offset : File offset, the start of the range to set to zeroes
   length : Byte length of the zeroed range
   Eg : fsutil file setzerodata offset=100 length=150 C:\Temp\sample.txt

To zero fill a complete file you will need to use an offset of 0 and you will need to know the file length.

Can we use batch file that would compute the size automatically?

Of course.

Use the following batch file (zero.cmd): 

@echo off
setlocal enabledelayedexpansion
for %%a in (%1) do (
  fsutil file setzerodata offset=0 length=%%~za %%a
)
endlocal

Usage:

  • You can pass a single filename as an argument: zero test.txt or a wildcard: zero *.txt

Example:

> type test.txt
abc
foo$
foo
bar

> zero test.txt
Zero data is changed

> type test.txt

>

enter image description here

Further Reading

DavidPostill
  • 162,382
2

Not exactly a solution, but if you have CygWin installed, you just do (example for a 500000000 bytes file) :

dd if=/dev/zero of=MyFile.zero bs=1 count=500000000

This is the same method you would use at any Unix-like operating system.

Sopalajo de Arrierez
  • 6,851
0

I know this question/thread is quite old, and the responses provided perfectly answer the question as it was asked. But the question itself is, in my opinion, seriously wrong, in that it asks how to apply the 'solution' to the problem that the OP has himself/herself 'devised/thought of'.

This question itself is a perfect example of how NOT to proceed to solve a problem, at least in such a critical context of data privacy/security/confidentiality, where any shortcoming, or simply overlooking any aspect of the matter may/will result in serious consequences.

Basically, what the Original Poster does is try to solve anew and on his own, using only his/her own (obviously) limited resources and knowledge of the matter, a problem that is not only neither new nor unknown, but may actually be (almost) as old as computing itself (if not as old as the paper shredder).

In a word, this simply is courting disaster.

This problem has been so amply discussed, documented and contextually solved in so many places where computing/data security and confidentiality are debated, that it is not just dumb not to start with at least some basic, and even better --due to the criticality of the matter-- some serious research, it is seriously wrong.

Just coming to mind, permanently erasing a file is tightly dependent on actual context : first on the Operating System of course, but also on the filesystem in use, which may be seriously more complex in the ways that it works, and extremely likely to use more varied and diverse structures than the standard user may assume.

So 'overwriting' the file 'in-place' (modifying the actual disk sectors / bytes of the file, not creating a new file), 'filling it' with zero / NULL bytes" may not actually solve the problem at all, and/or simply may be quite a lot more difficult than assumed. Doing this, and then checking the contents of the file afterwards by no means guarantee that the old data itself (i.e. the old blocks/sectors/clusters, or any other structure which held it) has actually been overwritten and does not remain intact and untouched where it was/is.

Also, even before concentrating on the files, on a higher level, it must be checked and ensured that there aren't any type of Backup or Replication active on the drive where the file(s) are stored (cloud, alternate drive or media, tape backup, etc.) which themselves may still hold copies of the targeted files.

And what about the application(s) that created or modified the files in the first place ? It must be ensured that they do not themselves create their own backup files (.bak or other extension), possibly stored on another drive / in another directory.

Once all this has been checked and is out of the way, in the specific context of Windows, for a hint of the issues and complexities of this problem, see the Introduction to the 'SDelete' tool by the always excellent Mark Russinovich (Published: September 29, 2023, as of April 2024) :
https://learn.microsoft.com/en-us/sysinternals/downloads/sdelete
Make sure not to miss the 'How SDelete works' section.

Finally, the nature of the storage media itself matter a lot too. Even assuming the files are on a local drive, are we talking about a Hard-Drive (HDD) or a Solid State Drive (SSD) ?

SSDs work in a very different way from that of HDDs.

About this, just on Superuser, check the following pages :
How to securely delete files stored on a SSD?
How to securely erase a specific folder from SSD?

Also, although this page may be a bit old and about a different question (overwriting already deleted files and free space on a drive), it raises and discusses issues that are exactly the same as when trying to overwrite and/or permanently delete still existing files :
How to overwrite deleted files completely the right way
Specifically check the answer by 'jww Oct 6, 2018 at 10:29' and the excellent links it provides.

The two links in question are here below. Make sure not to miss the first one, an excellent white paper on the issues with deleting data on solid state drives, which found bugs in some SSDs Secure Erase commands which 'in some cases, result in all the data remaining intact on the drive', and that 'Single-file sanitization techniques (...) consistently fail to remove data from the SSD" :
https://www.usenix.org/legacy/event/fast11/tech/full_papers/Wei.pdf

But the second one is interesting too :
How can I securely format a solid-state drive?
And on the above page, check the 'source' link provided to this one :
https://www.ghacks.net/2009/04/08/ssd-security-erase-solid-state-drives-data/

And remember that, as storage technology evolves over time (rather rapidly indeed), the problem may soon face new issues and require different solutions and actions.

BrunoB75
  • 1