From Newsgroup: alt.privacy.anon-server

Alan <nuh-uh@nope.com> on Sun, 30 Aug 2026 09:13:39 -0700 typed in alt.comp.os.windows-11 the following:

On 2026-08-29 10:39, Yamn Remailer wrote:

My high school computer teacher told us the only way to truly delete or erase files
is to smash your computer's hard drive with a sledgehammer!

https://www.youtube.com/watch?v=jdui7v2B9DI

Your high school computer teacher should take up a new subject.

You most definitely can "truly delete or erase files" on both magnetic
hard drives and most certainly on SSDs.

And your video actually explains how data can truly be erased.

I used to do "electronic discovery" - searching hard drives for evidence.
Suggestion one. Find a file or two, which are an integer number of "allocation size" in size. Game files are good for this. Copy "Source
File" to FileCopy(1..n) until drive is full.
This covers every byte of the drive with something else.
Delete all files. Copy smaller Afile, multiple time, to over write
the directory entries.

Because what happens when you copy files is that what is after the <EOF> but before the allocation limit also gets copied.

Example.
File Allocation size is 4096 bytes.
FileA is 40960 bytes.
It fills 10 allocation blocks
For i = (1..N) do
Copy FileA to FileA-i
end
this fills the drive with many files, over writing each allocation block.
It also overwrites directory entries with FileA-1 to FileA-N.

Then you take the drive to the range and shoot it full of bullets. Followed with baking in a kiln until the aluminum melts or catches
fire.
Overwrites the directory entry
--
pyotr filipivich
This Week's Panel: Us & Them - Eliminating Them.
Next Month's Panel: Having eliminated the old Them(tm)
Selecting who insufficiently Woke(tm) as to serve as the new Them(tm)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

In article <2agralltd01vct69mvhe0a3hg93naikq2q@4ax.com>
pyotr filipivich <pyotr13315@yahoo.com> wrote:

Alan <nuh-uh@nope.com> on Sun, 30 Aug 2026 09:13:39 -0700 typed in alt.comp.os.windows-11 the following:

On 2026-08-29 10:39, Yamn Remailer wrote:

My high school computer teacher told us the only way to truly delete or erase files
is to smash your computer's hard drive with a sledgehammer!

https://www.youtube.com/watch?v=jdui7v2B9DI

Your high school computer teacher should take up a new subject.

You most definitely can "truly delete or erase files" on both magnetic
hard drives and most certainly on SSDs.

And your video actually explains how data can truly be erased.

I used to do "electronic discovery" - searching hard drives for evidence.
Suggestion one. Find a file or two, which are an integer number of "allocation size" in size. Game files are good for this. Copy "Source
File" to FileCopy(1..n) until drive is full.
This covers every byte of the drive with something else.
Delete all files. Copy smaller Afile, multiple time, to over write
the directory entries.

Because what happens when you copy files is that what is after the <EOF> but before the allocation limit also gets copied.

Example.
File Allocation size is 4096 bytes.
FileA is 40960 bytes.
It fills 10 allocation blocks
For i = (1..N) do
Copy FileA to FileA-i
end
this fills the drive with many files, over writing each allocation block.
It also overwrites directory entries with FileA-1 to FileA-N.

Then you take the drive to the range and shoot it full of bullets. Followed with baking in a kiln until the aluminum melts or catches
fire.
Overwrites the directory entry

In windows format c: /P:1 or a higher number.
On a multi-terabyte HDD, this could run for days.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server


Yamn Remailer <noreply@mixmin.net> posted:

My high school computer teacher told us the only way to truly delete or erase files
is to smash your computer's hard drive with a sledgehammer!

https://www.youtube.com/watch?v=jdui7v2B9DI

With Glary Utilities (free), you can "shred" a file, meaning it gets overwritten
multiple times to comply with the US Dept. of Defense regulation for making a file
unrecoverable. There is also an option to wipe the free space, which will "shred"
the entire space that does not currently hold a valid file.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

On 18 Sep 2026, pyotr filipivich <pyotr13315@yahoo.com> posted some news:2agralltd01vct69mvhe0a3hg93naikq2q@4ax.com:

Alan <nuh-uh@nope.com> on Sun, 30 Aug 2026 09:13:39 -0700 typed in alt.comp.os.windows-11 the following:

On 2026-08-29 10:39, Yamn Remailer wrote:

My high school computer teacher told us the only way to truly delete
or erase files is to smash your computer's hard drive with a
sledgehammer!

https://www.youtube.com/watch?v=jdui7v2B9DI

Your high school computer teacher should take up a new subject.

You most definitely can "truly delete or erase files" on both magnetic
hard drives and most certainly on SSDs.

And your video actually explains how data can truly be erased.

I used to do "electronic discovery" - searching hard drives for evidence.
Suggestion one. Find a file or two, which are an integer number
of
"allocation size" in size. Game files are good for this. Copy "Source
File" to FileCopy(1..n) until drive is full.
This covers every byte of the drive with something else.
Delete all files. Copy smaller Afile, multiple time, to over
write
the directory entries.

Because what happens when you copy files is that what is after
the
<EOF> but before the allocation limit also gets copied.

Example.
File Allocation size is 4096 bytes.
FileA is 40960 bytes.
It fills 10 allocation blocks
For i = (1..N) do
Copy FileA to FileA-i
end
this fills the drive with many files, over writing each
allocation
block.
It also overwrites directory entries with FileA-1 to FileA-N.

Then you take the drive to the range and shoot it full of
bullets.
Followed with baking in a kiln until the aluminum melts or catches
fire.
Overwrites the directory entry

Did you ever experiement with this?

fsutil file createnew zeroes.txt 100000000 (Any size you want etc.)

Creates a file full of zeroes.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

On Mon, 9/21/2026 4:12 PM, Nomen Nescio wrote:

Did you ever experiement with this?

fsutil file createnew zeroes.txt 100000000 (Any size you want etc.)

Creates a file full of zeroes.

*********************** CoPilot Answer *****************************
**Short answer:** **`fsutil file createnew` does *not* write 93rC>GB of zeroes.**
It finishes instantly because it uses an NTFS metadata trick:
**it sets the file *valid data length* and *end-of-file* in the MFT
without actually writing the data blocks.** NTFS then *logically* treats
the file as containing zeroes, but the disk blocks are not physically written.

This is why creating a 93rC>GB file appears instantaneous.

---

### What actually happens inside NTFS
The command:

fsutil file createnew bigger.txt 93605473280

invokes the NTFS **SetEndOfFile** + **SetValidDataLength** operations. These do the following:

- **Allocate clusters** for the file in the MFT metadata (extent list).
- **Mark the file as having valid data up to the specified length.**
- **Do NOT write zeroes to disk.**

NTFS guarantees that any unwritten region of a file reads back as zeroes,
so it doesnrCOt need to physically write them. This is a filesystem invariant.

This behavior is explicitly documented:
- createnew *"creates a file of the specified name and size, with content that
consists of zeroes"* - but this is done by metadata, not by writing the zeroes.
( https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-file )
- It *prerCaallocates disk space by directly manipulating file system metadata*,
avoiding byterCabyrCabyte writes. ( https://devgex.com/en/article/00012348 )

---

### Why itrCOs so fast
Because NTFS only updates:

- The MFT entry
- The filerCOs allocation extents
- The valid data length

These are tiny metadata writes (hundreds of bytes), not gigabytes.

No disk I/O proportional to file size occurs.

---

### Important consequences
#### 1. **It is NOT a sparse file**
Multiple sources confirm that `fsutil file createnew` does *not* set the sparse flag.
( https://stackoverflow.com/questions/982659/quickly-create-large-file-on-a-windows-system )
The file really consumes disk space - itrCOs just not filled with zeroes by writing.

#### 2. **It does NOT test disk write speed**
If you need to actually force 93rC>GB of writes, this command wonrCOt do it.

#### 3. **Reading the file returns zeroes**
NTFS guarantees unwritten regions read as zeroes, so the file behaves like a zerorCafilled file.

---

### How Windows fills the file "instantly"
A key detail from Process Monitor analysis:
Tools like Contig create large files by **writing a single zero at the last byte**,
and NTFS implicitly zero-extends the rest.

( https://stackoverflow.com/questions/982659/quickly-create-large-file-on-a-windows-system )

fsutil createnew does something even simpler: it doesnrCOt write *any* data at all rCo it only sets metadata.

---

### Summary
`fsutil file createnew` finishes instantly because:

- It **does not write 93rC>GB of zeroes**
- It **only updates NTFS metadata**
- NTFS guarantees unwritten regions read as zeroes
- The file **does occupy disk space**, but without physical writes

This is a filesystemrCalevel optimization, not a diskrCalevel write. *********************** End: CoPilot Answer *****************************

So don't do that, OK ?

I checked with a hex editor. I filled a volume with /dev/random data,
deleted the file, then did the fsutil command.

Using hex edit directly on the zeroes.txt, it reads back zeros as you
scroll through it with hex edit.

The neat thing is, when you run HxD.exe as administrator and look at the physical layer of the disk, the /dev/random data is sitting there. The
zeros being "faked", cannot be seen.

This means your command is *absolutely useless* for erasing or filling anything.
If you delete zeroes.txt, the underlying content at the physical layer is still there.
All that random data I used as a marker of the physical layer is still there.

Whereas, the dd.exe command, if you use that command, it takes time to finish, it works at the layer you would expect, when issuing the command.
It can overwrite a partition or overwrite the entire storage device.
It depends on the status of a partition, whether the particular ancient
utility I use, works or not. We do this first, to check what we can
smash, before we smash stuff.

dd.exe --list # command prompt administrator window

rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.
...

NT Block Device Objects
\\?\Device\Harddisk0\Partition0 <=== The entire boot disk. Can write this (um, very bad...)
link to \\?\Device\Harddisk0\DR0
Fixed hard disk media. Block size = 512
size is 4000787030016 bytes
\\?\Device\Harddisk0\Partition1 <=== ESP. Cannot dd this.
link to \\?\Device\HarddiskVolume1
\\?\Device\Harddisk0\Partition2
link to \\?\Device\HarddiskVolume2 <=== Microsoft reserved. No file system.
Fixed hard disk media. Block size = 512
size is 16777216 bytes
\\?\Device\Harddisk0\Partition3
link to \\?\Device\HarddiskVolume3 <=== C: drive \\?\Device\Harddisk0\Partition4
link to \\?\Device\HarddiskVolume4 <=== Recovery partition
Fixed hard disk media. Block size = 512
size is 1073741824 bytes
...

\\?\Device\Harddisk1\Partition0 <=== My second disk
link to \\?\Device\Harddisk1\DR1
Fixed hard disk media. Block size = 512
size is 103809024000 bytes <=== Write-able, when you see this field
\\?\Device\Harddisk1\Partition1
link to \\?\Device\HarddiskVolume9 <=== D: partition is not writeable at the moment. Size not listed.

Virtual input devices
/dev/zero (null data)
/dev/random (pseudo-random data)
- (standard input)

Virtual output devices
- (standard output)
/dev/null (discard the data)

dd.exe if=/dev/zero of=D:\zeroes.txt bs=1M count=89000 <=== Physically writes 89000MB of zeros

3.8GB/sec, on D:

I had HxD open the whole time, and scrolling the Harddisk1 device,
there is none of that /dev/random data there any more. I erased it
with the dd.exe run .

"fsutil file createnew" is not UNIX mkfile, and should not be mistaken for one. It's a trap for the unwary. Any time a recipe finishes too fast, you should
be immediately suspicious.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

On 22 Sep 2026, Paul <nospam@needed.invalid> posted some news:118uh0k$13l2p$1@dont-email.me:

On Mon, 9/21/2026 4:12 PM, Nomen Nescio wrote:

Did you ever experiement with this?

fsutil file createnew zeroes.txt 100000000 (Any size you want etc.)

Creates a file full of zeroes.

*********************** CoPilot Answer *****************************
**Short answer:** **`fsutil file createnew` does *not* write 93rC>GB
of zeroes.** It finishes instantly because it uses an NTFS metadata
trick: **it sets the file *valid data length* and *end-of-file* in the
MFT without actually writing the data blocks.** NTFS then *logically*
treats the file as containing zeroes, but the disk blocks are not
physically written.

This is why creating a 93rC>GB file appears instantaneous.

---

### What actually happens inside NTFS
The command:

fsutil file createnew bigger.txt 93605473280

invokes the NTFS **SetEndOfFile** + **SetValidDataLength** operations.
These do the following:

- **Allocate clusters** for the file in the MFT metadata (extent
list). - **Mark the file as having valid data up to the specified
length.** - **Do NOT write zeroes to disk.**

NTFS guarantees that any unwritten region of a file reads back as
zeroes, so it doesnrCOt need to physically write them. This is a
filesystem invariant.

This behavior is explicitly documented:
- createnew *"creates a file of the specified name and size, with
content that
consists of zeroes"* - but this is done by metadata, not by writing
the zeroes. (
https://learn.microsoft.com/en-us/windows-

server/administration/wind

ows-commands/fsutil-file )
- It *prerCaallocates disk space by directly manipulating file system metadata*,
avoiding byterCabyrCabyte writes. (
https://devgex.com/en/article/00012348 )

---

### Why itrCOs so fast
Because NTFS only updates:

- The MFT entry
- The filerCOs allocation extents
- The valid data length

These are tiny metadata writes (hundreds of bytes), not gigabytes.

No disk I/O proportional to file size occurs.

---

### Important consequences
#### 1. **It is NOT a sparse file**
Multiple sources confirm that `fsutil file createnew` does *not* set
the sparse flag.
( https://stackoverflow.com/questions/982659/quickly-create-large-

file

-on-a-windows-system )
The file really consumes disk space - itrCOs just not filled with
zeroes by writing.

#### 2. **It does NOT test disk write speed**
If you need to actually force 93rC>GB of writes, this command wonrCOt
do it.

#### 3. **Reading the file returns zeroes**
NTFS guarantees unwritten regions read as zeroes, so the file behaves
like a zerorCafilled file.

---

### How Windows fills the file "instantly"
A key detail from Process Monitor analysis:
Tools like Contig create large files by **writing a single zero at the
last byte**, and NTFS implicitly zero-extends the rest.

( https://stackoverflow.com/questions/982659/quickly-create-large-

file

-on-a-windows-system )

fsutil createnew does something even simpler: it doesnrCOt write
*any* data at all rCo it only sets metadata.

---

### Summary
`fsutil file createnew` finishes instantly because:

- It **does not write 93rC>GB of zeroes**
- It **only updates NTFS metadata**
- NTFS guarantees unwritten regions read as zeroes
- The file **does occupy disk space**, but without physical writes

This is a filesystemrCalevel optimization, not a diskrCalevel write. *********************** End: CoPilot Answer
*****************************

So don't do that, OK ?

I checked with a hex editor. I filled a volume with /dev/random data,
deleted the file, then did the fsutil command.

Using hex edit directly on the zeroes.txt, it reads back zeros as you
scroll through it with hex edit.

The neat thing is, when you run HxD.exe as administrator and look at
the physical layer of the disk, the /dev/random data is sitting there.
The zeros being "faked", cannot be seen.

This means your command is *absolutely useless* for erasing or filling anything. If you delete zeroes.txt, the underlying content at the
physical layer is still there. All that random data I used as a marker
of the physical layer is still there.

Whereas, the dd.exe command, if you use that command, it takes time to finish, it works at the layer you would expect, when issuing the
command. It can overwrite a partition or overwrite the entire storage
device. It depends on the status of a partition, whether the
particular ancient utility I use, works or not. We do this first, to
check what we can smash, before we smash stuff.

dd.exe --list # command prompt administrator window rawwrite dd for windows version 0.6beta3.

Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.
...

NT Block Device Objects
\\?\Device\Harddisk0\Partition0 <=== The entire boot disk.
Can write this (um, very bad...)
link to \\?\Device\Harddisk0\DR0
Fixed hard disk media. Block size = 512
size is 4000787030016 bytes
\\?\Device\Harddisk0\Partition1 <=== ESP. Cannot dd this.
link to \\?\Device\HarddiskVolume1
\\?\Device\Harddisk0\Partition2
link to \\?\Device\HarddiskVolume2 <=== Microsoft reserved. No
file system. Fixed hard disk media. Block size = 512
size is 16777216 bytes
\\?\Device\Harddisk0\Partition3
link to \\?\Device\HarddiskVolume3 <=== C: drive \\?\Device\Harddisk0\Partition4
link to \\?\Device\HarddiskVolume4 <=== Recovery partition
Fixed hard disk media. Block size = 512
size is 1073741824 bytes
...

\\?\Device\Harddisk1\Partition0 <=== My second disk
link to \\?\Device\Harddisk1\DR1
Fixed hard disk media. Block size = 512
size is 103809024000 bytes <=== Write-able, when you
see this field
\\?\Device\Harddisk1\Partition1
link to \\?\Device\HarddiskVolume9 <=== D: partition is not
writeable at the moment. Size not listed.

Virtual input devices
/dev/zero (null data)
/dev/random (pseudo-random data)
- (standard input)

Virtual output devices
- (standard output)
/dev/null (discard the data)

dd.exe if=/dev/zero of=D:\zeroes.txt bs=1M count=89000 <===

Physically writes 89000MB of zeros

3.8GB/sec, on D:

I had HxD open the whole time, and scrolling the Harddisk1 device,
there is none of that /dev/random data there any more. I erased it
with the dd.exe run .

"fsutil file createnew" is not UNIX mkfile, and should not be mistaken
for one. It's a trap for the unwary. Any time a recipe finishes too
fast, you should be immediately suspicious.

It's pretty handy and I think you could make it do what the op asked. FAT/FAT32 would work okay, NTFS not so much. There could be some
personal data in the MFT record area, depends. Misuse: It can be used
to zero system files on infected system by ransonware code for example.

fsutil file createnew zeroes.txt 100000000

Try fsutil file setzerodata offset=0 length=100000000 zeroes.txt

It could take a while.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

Gabx tales:

Yamn Remailer wrote:

My high school computer teacher told us the only way to truly delete
or erase files
is to smash your computer's hard drive with a sledgehammer!

https://www.youtube.com/watch?v=jdui7v2B9DI

On Debian Sid i get rid of files throwing them in the bin.

This bin:

# RAM-backed XDG "Trash to RAM"; wiped on reboot
tmpfs /home/$USER/.local/share/Trash tmpfs defaults,size=4G,uid=1000,gid=1000,mode=0700 0 0

;)

Smart Efno !
--
creeping death
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

On 2026-09-22 20:22, Paul wrote:

On Mon, 9/21/2026 4:12 PM, Nomen Nescio wrote:

Did you ever experiement with this?

fsutil file createnew zeroes.txt 100000000 (Any size you want etc.)

Creates a file full of zeroes.

*********************** CoPilot Answer *****************************
**Short answer:** **`fsutil file createnew` does *not* write 93rC>GB of zeroes.**
It finishes instantly because it uses an NTFS metadata trick:
**it sets the file *valid data length* and *end-of-file* in the MFT
without actually writing the data blocks.** NTFS then *logically* treats
the file as containing zeroes, but the disk blocks are not physically written.

This is why creating a 93rC>GB file appears instantaneous.

---

neat trick.

...

### Important consequences
#### 1. **It is NOT a sparse file**

Wow. Curious thing. I was thinking about that.

I wonder if Linux has a similar trick.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

On 2026-09-22 11:22, Paul wrote:

On Mon, 9/21/2026 4:12 PM, Nomen Nescio wrote:

Did you ever experiement with this?

fsutil file createnew zeroes.txt 100000000 (Any size you want etc.)

Creates a file full of zeroes.

*********************** CoPilot Answer *****************************
**Short answer:** **`fsutil file createnew` does *not* write 93rC>GB of zeroes.**
It finishes instantly because it uses an NTFS metadata trick:
**it sets the file *valid data length* and *end-of-file* in the MFT
without actually writing the data blocks.** NTFS then *logically* treats
the file as containing zeroes, but the disk blocks are not physically written.

This is why creating a 93rC>GB file appears instantaneous.

How does NTFS "then *logically* treat[] the file as containing zeroes"

If one then reads the file, how does NTFS know not to read the actual
data that is IN those blocks?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

On Sun, 9/27/2026 2:56 PM, Alan wrote:

On 2026-09-22 11:22, Paul wrote:

On Mon, 9/21/2026 4:12 PM, Nomen Nescio wrote:

Did you ever experiement with this?

fsutil file createnew zeroes.txt 100000000 (Any size you want etc.)

Creates a file full of zeroes.

*********************** CoPilot Answer *****************************
**Short answer:** **`fsutil file createnew` does *not* write 93rC>GB of zeroes.**
It finishes instantly because it uses an NTFS metadata trick:
**it sets the file *valid data length* and *end-of-file* in the MFT
without actually writing the data blocks.** NTFS then *logically* treats
the file as containing zeroes, but the disk blocks are not physically written.

This is why creating a 93rC>GB file appears instantaneous.

How does NTFS "then *logically* treat[] the file as containing zeroes"

If one then reads the file, how does NTFS know not to read the actual data that is IN those blocks?

https://superuser.com/questions/1619084/what-does-the-command-fsutil-file-createnew-really-do

"The filesystem may keep two separate pointers - the 'end of file' as well as 'end of
valid data'. This is explicitly how NTFS works in Windows.

You can call SetEndOfFile() (corresponding to Linux ftruncate()) to create a large
file with no data, and the space between "end of valid data" and "end of file" will
automatically return all 0x00 bytes when read.

(Privileged accounts can actually use the SetFileValidData() call to force the OS to
return data that is already on disk, but it's not a commonly used operation.) "
Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

On 2026-09-27 12:51, Paul wrote:

On Sun, 9/27/2026 2:56 PM, Alan wrote:

On 2026-09-22 11:22, Paul wrote:

On Mon, 9/21/2026 4:12 PM, Nomen Nescio wrote:

Did you ever experiement with this?

fsutil file createnew zeroes.txt 100000000 (Any size you want etc.)

Creates a file full of zeroes.

*********************** CoPilot Answer *****************************
**Short answer:** **`fsutil file createnew` does *not* write 93rC>GB of zeroes.**
It finishes instantly because it uses an NTFS metadata trick:
**it sets the file *valid data length* and *end-of-file* in the MFT
without actually writing the data blocks.** NTFS then *logically* treats >>> the file as containing zeroes, but the disk blocks are not physically written.

This is why creating a 93rC>GB file appears instantaneous.

How does NTFS "then *logically* treat[] the file as containing zeroes"

If one then reads the file, how does NTFS know not to read the actual data that is IN those blocks?

https://superuser.com/questions/1619084/what-does-the-command-fsutil-file-createnew-really-do

"The filesystem may keep two separate pointers - the 'end of file' as well as 'end of
valid data'. This is explicitly how NTFS works in Windows.

You can call SetEndOfFile() (corresponding to Linux ftruncate()) to create a large
file with no data, and the space between "end of valid data" and "end of file" will
automatically return all 0x00 bytes when read.

(Privileged accounts can actually use the SetFileValidData() call to force the OS to
return data that is already on disk, but it's not a commonly used operation.)
"
Paul

And none of that will protect you if someone does a raw scan of the
drive's blocks.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

On Sun, 9/27/2026 5:28 PM, Alan wrote:

On 2026-09-27 12:51, Paul wrote:

On Sun, 9/27/2026 2:56 PM, Alan wrote:

On 2026-09-22 11:22, Paul wrote:

On Mon, 9/21/2026 4:12 PM, Nomen Nescio wrote:

Did you ever experiement with this?

fsutil file createnew zeroes.txt 100000000 (Any size you want etc.)

Creates a file full of zeroes.

*********************** CoPilot Answer *****************************
**Short answer:** **`fsutil file createnew` does *not* write 93rC>GB of zeroes.**
It finishes instantly because it uses an NTFS metadata trick:
**it sets the file *valid data length* and *end-of-file* in the MFT
without actually writing the data blocks.** NTFS then *logically* treats >>>> the file as containing zeroes, but the disk blocks are not physically written.

This is why creating a 93rC>GB file appears instantaneous.

How does NTFS "then *logically* treat[] the file as containing zeroes"

If one then reads the file, how does NTFS know not to read the actual data that is IN those blocks?

https://superuser.com/questions/1619084/what-does-the-command-fsutil-file-createnew-really-do

"The filesystem may keep two separate pointers - the 'end of file' as well as 'end of
-a valid data'. This is explicitly how NTFS works in Windows.

-a You can call SetEndOfFile() (corresponding to Linux ftruncate()) to create a large
-a file with no data, and the space between "end of valid data" and "end of file" will
-a automatically return all 0x00 bytes when read.

-a (Privileged accounts can actually use the SetFileValidData() call to force the OS to
-a return data that is already on disk, but it's not a commonly used operation.)
"
-a-a-a Paul

And none of that will protect you if someone does a raw scan of the drive's blocks.

Which is what I did, to prove the command could
not erase anything in zero microseconds. Ran HxD
as Administrator, and then the old data (the real
material on those sectors) showed through.

Even when a command takes finite time, you still have
to verify whether it was doing "reads" or "writes"
in the time interval. A format that does a bad block
scan, takes a finite time, but does not erase much
of anything for you. The writes would include a
new $MFT, but much of the rest of the disk activity
is reads.

If you change the encryption key on a drive, that achieves
"erasure" instantly, but that assumes the previous key cannot
be recovered. And we don't know how keys are handled in there.
This capability was used by ransomware at one point.

Paul

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.privacy.anon-server

On 27 Sep 2026, Alan <nuh-uh@nope.com> posted some news:119c1q0$1oso7$1@dont-email.me:

On 2026-09-27 12:51, Paul wrote:

On Sun, 9/27/2026 2:56 PM, Alan wrote:

On 2026-09-22 11:22, Paul wrote:

On Mon, 9/21/2026 4:12 PM, Nomen Nescio wrote:

Did you ever experiement with this?

fsutil file createnew zeroes.txt 100000000 (Any size you want
etc.)

Creates a file full of zeroes.

*********************** CoPilot Answer
***************************** **Short answer:** **`fsutil file
createnew` does *not* write 93rC>GB of zeroes.** It finishes
instantly because it uses an NTFS metadata trick: **it sets the
file *valid data length* and *end-of-file* in the MFT without
actually writing the data blocks.** NTFS then *logically* treats
the file as containing zeroes, but the disk blocks are not
physically written.

This is why creating a 93rC>GB file appears instantaneous.

How does NTFS "then *logically* treat[] the file as containing
zeroes"

If one then reads the file, how does NTFS know not to read the
actual data that is IN those blocks?

https://superuser.com/questions/1619084/what-does-the-command-fsutil-

f

ile-createnew-really-do

"The filesystem may keep two separate pointers - the 'end of file' as
well as 'end of
valid data'. This is explicitly how NTFS works in Windows.

You can call SetEndOfFile() (corresponding to Linux ftruncate()) to
create a large file with no data, and the space between "end of
valid data" and "end of file" will automatically return all 0x00
bytes when read.

(Privileged accounts can actually use the SetFileValidData() call
to force the OS to return data that is already on disk, but it's
not a commonly used operation.)
"
Paul

And none of that will protect you if someone does a raw scan of the
drive's blocks.

That depends if anything was ever there.

--- Synchronet 3.22a-Linux NewsLink 1.2