[quote=andymbody post_id=536394 time=1693267559 user_id=79819]
Was that referenced post yours @SKAN or @lexikos ?[/quote]

FormatBytes1() was by me and FormatBytes2() was by [mention]lexikos[/mention] both posted in the [url=https://www.autohotkey.com/boards/viewtopic.php?t=3567]same topic[/url].

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

[quote=SKAN post_id=536277 time=1693220158 user_id=54]
Then I suppose @lexikos method is better?
[/quote]

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

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 [mention]SKAN[/mention] or [mention]lexikos[/mention] ?



[quote=SKAN post_id=536298 time=1693228309 user_id=54]
Are you sure? :? Seems like only 3 bytes short?
[/quote]

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.



[quote="A Keymaker" post_id=536279 time=1693220537 user_id=145978]
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?
[/quote]

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 [mention]SKAN[/mention] ... and everyone!!
Andy

[quote=SKAN post_id=536298 time=1693228309 user_id=54]
Are you sure? :? Seems like only 3 bytes short?
[/quote]

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

#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")
}

#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)

[quote=andymbody post_id=536179 time=1693154295 user_id=79819]
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 [color=#FF0000]409 bytes[/color] to report 19.9, and I can't figure out why?
[/quote]

Are you sure? :? Seems like only 3 bytes short?
[code]#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")
}
[/code]
 
[color=#FF0000]Edit:[/color]
I created a file to test:
[code]
#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)
[/code]
 
[indent=4][attachment=0]image.png[/attachment][/indent]

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?

#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")
}

[quote=andymbody post_id=536268 time=1693218937 user_id=79819]
But this is not my question.
[/quote]
 
:oops: Sorry!
I didn't read past [c]Can anyone tell me why the OS has reported 19.8mb rather than 19.9mb for FileSize?[/c].

[quote=andymbody post_id=536268 time=1693218937 user_id=79819]
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.
[/quote]
 
Then I suppose [mention]lexikos[/mention] method is better?
Ref: [url=https://www.autohotkey.com/boards/viewtopic.php?t=3567]FormatBytes()[/url]
 
[code]#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")
}[/code]

[quote=SKAN post_id=536260 time=1693215311 user_id=54]
[/quote]

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

#Requires AutoHotkey v2.0
#SingleInstance

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

[b][u]Example first:[/u][/b]
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
[u]Used/Free Storage Qty:[/u]
Qty used: 8 litres
Qty free: 12 litres
 
[b][i]Allocation unit[/i][/b] is the smallest logical amount of disk space that can be allocated to hold a file.
This is most commonly 4096 bytes
 
[indent=4]
[attachment=1]image.png[/attachment]
[/indent]
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 [b][i]Size on disk[/i][/b] will always be divisible by cluster size (4096),
and the [b][i]Size on disk[/i][/b] 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]#Requires AutoHotkey v2.0
#SingleInstance

TxtFile := A_Temp "\~ahktest.txt"
Try FileDelete(TxtFile)
FileAppend("SKAN", TxtFile)
RunWait('properties "' TxtFile '"')
WinWait("~ahktest")
WinWaitClose("~ahktest")[/code]
 
[indent=4]
[attachment=0]image.png[/attachment]
[/indent]
 

[color=#FF0000]Edit[/color]: Read
[url=https://www.foldersizes.com/wordpress/index.php/2020/07/actual-vs-allocated-disk-space.htm#:~:text=A%20rough%20estimate%20of%20wasted,about%2097MB%20of%20disk%20space.]ACTUAL VS. ALLOCATED DISK SPACE[/url]
[url=https://support.microsoft.com/en-us/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95]Default cluster size for NTFS, FAT, and exFAT[/url]

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.

[attachment=0]File size improper calculation.jpg[/attachment]

Can anyone tell me why the OS has reported [color=#FF0000]19.8mb[/color] rather than [color=#00BF00]19.9mb[/color] 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 [color=#00BF00]19.9mb[/color], rather than [color=#FF0000]19.8mb[/color].

[color=#00BF00]20,867,069 / (1024*1024) = 19.900387764[/color]

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 [color=#FF0000]409 bytes[/color] 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