Windows file size calculation? Topic is solved

[andymbody]

During my AHK project, I noticed something that I do not understand about the way Windows (7) calculates/reports the file size within the Properties dialog.

File size improper calculation.jpg (5.4 KiB) Viewed 8167 times

Can anyone tell me why the OS has reported 19.8mb rather than 19.9mb for FileSize?

I understand that the value is "floored" at the first decimal point, rather than rounded. But even with this, this should still report 19.9mb, rather than 19.8mb.

20,867,069 / (1024*1024) = 19.900387764

My calculations within my project don't match what Windows reports (regarding abbreviated size). In my investigation for a reason, I found that Windows requires another 409 bytes to report 19.9, and I can't figure out why?

Obviously this is not a critical issue since I use actual bytes for my calculations, which does match Windows exactly. I was just curious as to why there is a difference, and if anyone may be able to provide insight regarding the inner workings of the OS formula being used to abbreviate the size.

Thanks! Andy

[SKAN]

Example first:
You have 10 empty bottles with 2 litres capacity each, 20 litres total capacity.
You buy/store fuel, Petrol 3 litres and Diesel 3 litres.
Then listing would be:
Petrol Actual Qty: 3 litres and Storage Qty used: 4 litres
Diesel Actual Qty: 3 litres and Storage Qty used: 4 litres
Used/Free Storage Qty:
Qty used: 8 litres
Qty free: 12 litres
 
Allocation unit is the smallest logical amount of disk space that can be allocated to hold a file.
This is most commonly 4096 bytes
 

image.png (11.89 KiB) Viewed 8145 times

So, a file sized 5000 bytes will occupy 2 allocation units (also known as clusters).
Size: 5000 bytes
Size on disk: 8192 bytes

Therefore the formula is Size on disk will always be divisible by cluster size (4096),
and the Size on disk will never exceed actual size by more than cluster size.
 
In NTFS, a MFT record size is usually 1024 bytes and small files are directly stored in record itself.
For example:

Code: Select all

#Requires AutoHotkey v2.0
#SingleInstance

TxtFile := A_Temp "\~ahktest.txt"
Try FileDelete(TxtFile)
FileAppend("SKAN", TxtFile)
RunWait('properties "' TxtFile '"')
WinWait("~ahktest")
WinWaitClose("~ahktest")

 

image.png (24.43 KiB) Viewed 8145 times

 

Edit: Read
ACTUAL VS. ALLOCATED DISK SPACE
Default cluster size for NTFS, FAT, and exFAT

[andymbody]

Thanks for the reply. I understand about allocation units and that files can (and almost always do) take up more disk space than is required for the actual file size in bytes. And this is the usual question that most people ask. But this is not my question.

If we ignore the "size on disk" attribute, why does Windows report that

20867069 / 1048576 = 19.8, rather than 19.9?

This simple math does not add (or divide) up. Plug it into any calculator, and 19.8 should never be the answer.

Andy

[SKAN]

But this is not my question.

 
Sorry!
I didn't read past Can anyone tell me why the OS has reported 19.8mb rather than 19.9mb for FileSize?.

If we ignore the "size on disk" attribute, why does Windows report that

20867069 / 1048576 = 19.8, rather than 19.9?

This simple math does not add (or divide) up. Plug it into any calculator, and 19.8 should never be the answer.

 
Then I suppose @lexikos method is better?
Ref: FormatBytes()
 

Code: Select all

#Requires AutoHotkey v2.0
#SingleInstance

MsgBox  FormatBytes1(20867069)
 . "`n" FormatBytes2(20867069)


FormatBytes1(N) { ; By SKAN on CT5H/D351 @ tiny.cc/formatbytes
Return DllCall("Shlwapi\StrFormatByteSize64A", "Int64",N, "Str",Format("{:16}",N), "Int",16, "AStr")
}

FormatBytes2(bytes){ ; By lexikos @ autohotkey.com/r?p=97571
	Loop
		If bytes > 999
			bytes /= 1024.0
		else return RTrim(SubStr(bytes,1,4),".") " " (A_Index=1 ? "bytes" : SubStr(" KMGTPEZY",A_Index,1) "B")
}

[A Keymaker]

What about individual programs: can some of them do their own calculations - or do they all relay on what Windows reports to them?

If they so their own, then have you compared end results?

[SKAN]

My calculations within my project don't match what Windows reports (regarding abbreviated size). In my investigation for a reason, I found that Windows requires another 409 bytes to report 19.9, and I can't figure out why?

Are you sure? Seems like only 3 bytes short?

Code: Select all

#Requires AutoHotkey v2.0
#SingleInstance

MsgBox  FormatBytes1(20867069+3)

FormatBytes1(N) { ; By SKAN on CT5H/D351 @ tiny.cc/formatbytes
Return DllCall("Shlwapi\StrFormatByteSize64A", "Int64",N, "Str",Format("{:16}",N), "Int",16, "AStr")
}

 
Edit:
I created a file to test:

Code: Select all

#Requires AutoHotkey v2.0
#SingleInstance

TxtFile := A_Temp "\~ahktest.txt"
Try FileDelete(TxtFile)
Text := Format("{:20867072}", "")
FileAppend(Text, TxtFile)
Run('properties "' TxtFile '"')
WinWait("~ahktest")
WinWaitClose("~ahktest")
Try FileDelete(TxtFile)

 

image.png (25.8 KiB) Viewed 8106 times

[andymbody]

Are you sure? Seems like only 3 bytes short?

I did a lot of testing on this (too much, I'm embarrassed to say). It is possible that posted the screenshot that does not reflect my exact statement. I will have to look to see when I get back to my computer.

I will also dig into your test...

Thank you for the reply and your time

[andymbody]

Then I suppose @lexikos method is better?

Code: Select all

DllCall("Shlwapi\StrFormatByteSize64A", "Int64",N, "Str",Format("{:16}",N), "Int",16, "AStr")

Yes! This produces exactly the same results as Windows is reporting. I should use this for formatting going forward so that the values are consistent with the Windows properties, if/when I make comparisons, especially during debugging. Was that referenced post yours @SKAN or @lexikos ?

Are you sure? Seems like only 3 bytes short?

Yes, you are correct... I posted a snapshot that did not reflect the original 409 bytes that I saw in the beginning. Sorry about that. The snapshot was of the edit I made to the file to add characters until I saw the change between 19.8 and 19.9. I think I subtracted a couple characters from that point just before I took the snapshot. Nice catch, BTW.

What about individual programs: can some of them do their own calculations - or do they all relay on what Windows reports to them?
If they so their own, then have you compared end results?

Sorry, I don't think I understand this comment/question... but... if I do... yes, the program does do it's own calculation, and does not rely on Windows for that. But, during testing/debugging, I noticed that my code was not producing the same results that Windows was reporting. I was using Windows reporting as a benchmark to determine whether the code was producing the correct result for that particular function. It wasn't, so I had to investigate, which led to this post.


Thank you @SKAN ... and everyone!!
Andy

[SKAN]

Was that referenced post yours @SKAN or @lexikos ?

FormatBytes1() was by me and FormatBytes2() was by @lexikos both posted in the same topic.