Human-readable size bug? KB4471324 says 86.90 GB but actual only ` 799.0 MB

[dukechem]

No description provided.

[dukechem]

First thanks for all the work, and I apologize that this issue somehow got submitted as #21 -#37. I closed 21-36 leaving this one as #37.

In 3 all versions I tested: 0.7a, 0.8a, and newest 0.9a, for KB4471324 wumgr says obviously way too big size of 86.90 GB. Googling " KB4471324 size" says actual size should be around 799.0 MB.

I am guessing issue is in code snippet below from FileOps.cs
`
class FileOps

12 | {
13 | static public string FormatSize(decimal size)
14 | {
15 | if (size == 0)
16 | return "";
17 | if (size > 1024 * 1024 * 1024)
18 | return (size / (1024 * 1024 * 1024)).ToString("F") + " GB
`
My guess is that above code may need tweaking to use examples here:
https://stackoverflow.com/questions/281640/how-do-i-get-a-human-readable-file-size-in-bytes-abbreviation-using-net

Sorry I don't have time to fork and try to fix right now. Thanks again for all the work!

[Gurthurb]

The FormatSize method in FileOps.cs is slightly incorrect; its size checks should use >= and not >, because otherwise e.g. 1024*1024 will return 1024,00 KB instead of 1,00 MB.

But that can't be the reason for the KB4471324 size issue - I'm guessing it's caused by the Windows Update servers reporting an incorrect size?

[demovirus]

I have been facing this bug for a long time in WUMT. So it's likely connected with Microsoft update service.

[DavidXanatos]

the >= will be fixed in the next build.

about the totaly wrong size, yes its what windows reports no way to fix that imho