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.
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
Windows file size calculation? Topic is solved
Re: Windows file size calculation?
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
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:
Edit: Read
ACTUAL VS. ALLOCATED DISK SPACE
Default cluster size for NTFS, FAT, and exFAT
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
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")
Edit: Read
ACTUAL VS. ALLOCATED DISK SPACE
Default cluster size for NTFS, FAT, and exFAT
Re: Windows file size calculation?
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
Re: Windows file size calculation?
Sorry!
I didn't read past Can anyone tell me why the OS has reported 19.8mb rather than 19.9mb for FileSize?.
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
- Posts: 455
- Joined: 31 May 2022, 13:46
- Location: Donjon du Château de Mérovingien
Re: Windows file size calculation?
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?
If they so their own, then have you compared end results?
Re: Windows file size calculation? Topic is solved
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)
Re: Windows file size calculation?
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
Re: Windows file size calculation?
Code: Select all
DllCall("Shlwapi\StrFormatByteSize64A", "Int64",N, "Str",Format("{:16}",N), "Int",16, "AStr")
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.
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.A Keymaker wrote: ↑28 Aug 2023, 06:02What 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?
Thank you @SKAN ... and everyone!!
Andy
Re: Windows file size calculation?
Return to “Off-topic Discussion”
Who is online
Users browsing this forum: No registered users and 19 guests