1

I've written a tool that creates textfiles which are each 1GB big. Now when I execute the tool two times, Windows tells me that 4 GB of storage are now full, when it actually has to be just 2. Here is an example as a picture, cause I am not too good in explaining:

Windows without Textfiles:

enter image description here

Windows with Textfiles:

enter image description here

It varies between 106 GB and 105 GB, but I don't understand why. It shows 4-5GB less space when it's just 2GB less space. I could understand if it shows 3 GB less, cause maybe it's slightly more than 2GB, but 4?

Improve this question
5
  • What does windows tell if you ask the size of these 2 files? So don't call the diskspace but the properties for both files? Also, is this on an SSD or traditional disk?
    – LPChip
    Mar 12, 2020 at 13:03
  • Windows say, each file is 0.97GB big, and I'm using an SSD
    – DudeWhoWantsToLearn
    Mar 12, 2020 at 13:05
  • How does your tool generate those files? Are they completely allocated as a 1GB memory buffer and then written to disk. Or does your tool start with an empty file and gradually adds data until it reaches 1GB? If the first situation is true that memory-allocation could grow the pagefile by 1GB each time you run the tool.
    – Tonny
    Mar 12, 2020 at 13:11
  • Well, I just have a string with one space "␣". I double it "␣␣", I double it again "␣␣␣␣" etc, for 28 times. Then I write the generated string into the text file and reset the string to one space. I do this until I get the 1.024.000KB
    – DudeWhoWantsToLearn
    Mar 12, 2020 at 13:18
  • @DudeWhoWantsToLearn That is a VERY inefficient way to generate a 1 GB file consisting of spaces. Just allocate a 1 Megabyte array of bytes. Set every byte to 32 (ascii code for a space) and write that array to disk 1024 times. Depending on your programming language your method could account for the loss of diskspace by growth of the swapfile.
    – Tonny
    Mar 12, 2020 at 16:35

1 Answer 1

Reset to default
2

Given that you are using an SSD, the file is written to blocks on the SSD, and windows calculates the free space based upon free blocks.

This effectively means that the file is stored 100% in one block and 1% in the next. Windows calculates this as 2GB while effectively it is still 1GB. When your disk is sufficiently full, the rest of the block will be filled, so you have not lost the space, but due to your file being big enough to fill in the next block, and windows calculates it quickly, the information you see is simply incorrect, aka inaccurate.

Improve this answer
4
  • 1
    I sincerely doubt that. Those blocks aren't 1 GB in size. You are talking about file-system sectors that are typically 4 Kilobyte for a small (250GB) disk. Not Gigabytes.
    – Tonny
    Mar 12, 2020 at 13:22
  • @Tonny No, I'm talking about the SSD blocks that partition the disk in such way that file access is quick, and Windows using the information the SSD provides.
    – LPChip
    Mar 12, 2020 at 15:33
  • I really don't understand what you are getting that. The only blocks of consideration for diskdevices are filesystem clusters (typically 4K), blockdevice sectors (1K or 4K for most drives) and wear-leveling stripes (SSD only). Those wear-leveling stripes are invisible to the OS and typically 1 to 2 megabyte in size. Largest I have ever seen where 16 Megabyte. But there is nothing that operates in blocksize of 1 Gigabyte as you imply.
    – Tonny
    Mar 12, 2020 at 16:28
  • I am indeed talking about the wear levelling stipes. I speak from experience that when a file is really big, the SSD changes how the OS perceives the file. It is weird, but test it out yourself and you will find that this is actually the case. It only applies to SSD's not HDD's.
    – LPChip
    Mar 12, 2020 at 16:54

You must log in to answer this question.

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