4 ms·

Yeah, "in order to create a file of N MB, just seek to the offset you need and write 0 bytes" has been one of my favorite pieces of trivia for a long while -- t

Yeah, "in order to create a file of N MB, just seek to the offset you need and write 0 bytes" has been one of my favorite pieces of trivia for a long while -- this pattern even survives in Win32's SetFilePointer. On Windows, the resulting file is guaranteed to have any intervening bytes zero-initialized, but for DOS, that wasn't always the case, and any thus-created file could recycle previously deleted data, especially on redirected filesystems (e.g. LAN Manager or Novell NetWare volumes).

rep_lodsb 2y ago
I don't think DOS ever wrote zeroes when extending a file (except when using the FCB function "write random with zero fill"). On a single-user system, you'd only get back your own deleted data, so this at least can't be considered a security problem. It definitely is a problem if a network server extends files that way! NTFS has a "zero fill" flag that the OS sets for newly allocated blocks, so it doesn't actually have to fill them on disk - it can just return zeroes when an application tries to read from a part of the file that hasn't been written yet. I believe ext4 and all other modern filesystems have this optimization as well.
- diggernet 2y ago
  It's only not a security problem if the file never leaves that single user system. Which was definitely not a safe assumption, even then.
- PreInternet01 2y ago
  > you'd only get back your own deleted data That depends: if the operation was on a floppy you got from someone else, that data might very well be theirs. > NTFS has a "zero fill" flag True, but irrelevant: the Windows API guarantees the "seeking to an offset greater than the file length and then writing anything, including nothing, will fill the intervening bytes with zeroes" behavior. How this translates to the underlying file system (which may very well not be NTFS) is an implementation detail.

rep_lodsb 2y ago

I don't think DOS ever wrote zeroes when extending a file (except when using the FCB function "write random with zero fill"). On a single-user system, you'd only get back your own deleted data, so this at least can't be considered a security problem. It definitely is a problem if a network server extends files that way! NTFS has a "zero fill" flag that the OS sets for newly allocated blocks, so it doesn't actually have to fill them on disk - it can just return zeroes when an application tries to read from a part of the file that hasn't been written yet. I believe ext4 and all other modern filesystems have this optimization as well.

diggernet 2y ago
It's only not a security problem if the file never leaves that single user system. Which was definitely not a safe assumption, even then.
PreInternet01 2y ago
> you'd only get back your own deleted data That depends: if the operation was on a floppy you got from someone else, that data might very well be theirs. > NTFS has a "zero fill" flag True, but irrelevant: the Windows API guarantees the "seeking to an offset greater than the file length and then writing anything, including nothing, will fill the intervening bytes with zeroes" behavior. How this translates to the underlying file system (which may very well not be NTFS) is an implementation detail.