2 ms·

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 onl

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.