#197 FolderSize: Options for size units

[Ricky Tigg]

The display of sizes in FolderSize differ slightly from File Explorer in Windows. While they use the same unit convention (KB = 1024 bytes), there are rounding differences. Also, File Explorer consistently uses KB, while FolderSize also uses MB and GB when appropriate to display smaller and more readable numbers. It would be nice to have the option to use the same convention as File Explorer, so that reported sizes are directly comparable.

Also, it would be nice to have the option to use the IEC 80000-13 standard (KiB, MiB, GiB), as to eliminate the conflict and confusion between the Windows convention and metric prefixes (SI standard).

And, it would be nice to have the option to use metric prefixes (kB = 1000 bytes), e.g. to compare hard drive sizes (which are reported by drive vendors using metric prefixes), or to compare sizes with those reported by other programs and platforms using metric prefixes.

PS. Thanks to @rickytigg for highlighting these issues. The scope of this ticket has since been broadened to cover size unit options in general. The ticket title and description have been updated accordingly.

[Ricky Tigg]

References: https://www.iso.org, https://ansi.org

"FolderSize: Size units based on powers of 2 " | Developers, not quite a valid title you set.

Well, back to school! Smallest units size prefixes symbols according to SI and ISO/IEC in this regard are dully documented respectively as
k (kilo) and Ki (kibi) which are themselves according to b^n, where b is the base and n the exponent (n, integer >0), respectively power of 1000 ((10^3)^n, 1000^n) and power of 1024 ((2^10)^n, 1024^n).

Assign value 1 for n to demonstrate smallest unit size prefixes symbols of those standards: 1000^1=1000, and 1024^1=1024. Assign any n>1 to demonstrate correlation to others existing prefixes symbols of those standards.

• Neither base 10, nor base 2, for n are defined by those standards in this regard.
• Neither 10^n, nor 2^n, for n demonstrate any correlation to existing prefixes symbols of those standards.

[Vidar Hasfjord]

Hi Ricky,

Sorry, I found your posts a bit difficult to read, so I've attempted to simplify. I presume you simply want FolderSize to follow the Windows convention. Correct?

Well, back to school!

The Windows convention uses powers of two:

• KB = 2¹⁰ = 1024¹
• MB = 2²⁰ = (2¹⁰)² = 1024²
• GB = 2³⁰ = (2¹⁰)³ = 1024³
• etc.
  
  

See table: https://en.wikipedia.org/wiki/Byte#Multiple-byte_units

PS. More and more programs use the IEC standard (KiB, MiB, etc.) to be unambiguous. So that is my recommendation.

[Ognyan Chernokozhev]

Currently, FolderSize uses the same display convention as Windows Explorer.

For example, if you right-click on a folder, and select Properties, the displayed size of that folder is roughly the same as what FolderSize shows (slight difference in rounding) - see screenshot.

I agree that what Windows shows is not according to the scientific standards. This leads to issues that the 1TB drive that I have bought and installed, is displayed as 931GB in Windows Explorer.

We can easily start displaying the sizes as KiB, MiB and GiB, and also add a setting to switch between the standard convention (base 1000) and the Windows convention (based on 1024)

[Vidar Hasfjord]

@jogybl wrote:

Currently, FolderSize uses the same display convention as Windows Explorer.

Ah — so it does! I should have checked. That makes this ticket moot then.

We can easily start displaying the sizes as KiB, MiB and GiB

That gets my vote, as these units are unambiguous and hence eliminate any confusion.

and also add a setting to switch between the standard convention (base 1000) and the Windows convention (based on 1024)

An option to use SI standard (metric) units would be nice, but note that kilo is abbreviated with lower-case "k" in the SI standard, i.e. "kB" not "KB". This visual difference versus the Windows convention ("KB") may serve as a little reminder of what the units mean, when the metric option is in effect.

See table: https://en.wikipedia.org/wiki/Byte#Multiple-byte_units

PS. Rename this ticket to "FolderSize: Option for metric size units"?

[Ognyan Chernokozhev]

Another thing is that in the file list, the Windows Explorer currently displays all sizes as KB

even if the file is very small - like 300 bytes - it is still displayed as 1KB

and large files as well - for example my pagefile.sys size at the moment is displayed as 7,864,320 KB

Wonder if that would also be a useful option to add?

[Vidar Hasfjord]

@jogybl wrote:

Wonder if [display of all sizes as KB] would also be a useful option to add?

I noticed that too in File Explorer. It could be a useful option to have, to make comparisons between the programs easier, I guess. If you expand the option to allow selection of the unit to use as the consistent one, then you also cover Ricky's other request for using "bytes" for accuracy [feature-requests:#198].

[Erwin Lotter]

even if the file is very small - like 300 bytes - it is still displayed as 1KB

Might this be the difference between file size and disk usage?

[Ognyan Chernokozhev]

I don't think so. Although there are allocation units, and even a one-byte file still can take a certain block on disk that cannot be used for anything else, in most cases that block size is different.

When you open the properties of a file, it lists both "Size" and "Size on disk" - the second one shows the total size of allocation blocks used by the file.

On my disk, for small files, it is displayed as 4.00KB (4,096 bytes)

Note that for large files, if you enable disk compression, the (Size on disk) can be smaller than the actual file size.

FolderSize displays both the actual and the compressed size if they are different.

[Ricky Tigg]

@vattila | "Windows convention uses powers of two"

Note: validity of statements "power of two" and "power of ten not yet examined.

Be the expression "<power> of <base></power>" (n of b) with n for <power>, b for <base>.
In the context of digital storage size, in common sense the expression is valid for each n, (integer >0) . Values 2, 10, 1024 and 1000 of b are involved in this context in various literature. profane and canonical, then we can examine formulae that support them.</power>

• Values 1024 and 1000 of b do meet the requirement set by common sense. Both are valid for each n.

• Values 2 and 10 of b do not meet the requirement set by common sense. They are not valid for each n but for isolated cases.

  Demonstration
  

"MB = 2^20 = (2^10)^2 = 1024^2" ; (mention B not needed to demonstrate)

• Incoherent syntax observable before even examining the formulae itself. as you can noticed it by yourself "M =" and "2^20 = (2^10)^2 = 1024^2" are not compatible together.

• Coherent syntax would be: "M = 10^(3x2) = 10^6".

  Though since you intended to exhibit a syntax illustrating what you meant by "power of 2", here it is, rectified and therefore in coherent syntax:
  "Mi = 2^(10x2) = 2^20 = 1024^2"

  So here it was:! n is here a multiple of 10, (10x, (x, integer >0)). So you won't achieve a "power of 2" but at best a "power of 2 for each n multiple of 10 only".
  Now case of "power of 10". n is here a multiple of 3, (3x, , (x, integer >0)). So you won't achieve a "power of 10 " but at best a "power of 10 for each n multiple of 3 only".

@jogybl | "Currently, FolderSize uses the same display convention as Windows Explorer."

Since it as been demonstrated that FolderSize used a wrong convention then program making use of such convention would at most illustrate once more that state.

@vattila | "these units are unambiguous and hence eliminate any confusion."

No confusion does exist by itself. An author of the confusion is likely needed so that a confusion exists.. User is not involved in the production of code so far. The ISO/IEC standard appears the only one appropriate for expressing digital storage size as its prefixes are multiple of 8, which is equivalent to the byte size in bit, not multiple of 10,.

"An option to use SI standard (metric) units would be nice, but note that kilo is abbreviated with lower-case "k" in the SI standard, i.e. "kB" not "KB"."

Case matters. Carefully check symbols characters inserted in code against their meanings in official documentation; e.g. in SI , K alone stands for kelvin, not kilo.

[Vidar Hasfjord]

@rickytigg wrote:

Be the expression [...]

Thanks for your clarifications. I did a course on "formal specification" in university, but it is decades ago now. Being precise about technical matters can be helpful, sometimes crucial. However, in this case, I am sure Ognyan has the gist of the matter by now.

I have broadened the scope of this ticket to cover size unit options in general, as discussed. The ticket title and description have been updated accordingly. Let me know if you are happy with it.

[Ricky Tigg]

I was already pleased to acquire this software on Windows' side as FOSS. I wish i could have a translation file to make the interface language in Finnish.

[Vidar Hasfjord]

I wish I could have a translation file to make the interface language in Finnish.

Good suggestion! Feel free to add another request ticket for this. We do not currently have an OWLNext example that shows how to provide multiple language support, so it would be great to have one.

PS. By the way, regarding language support in the OWLNext library, see "Translations" [feature-requests:#86].

[Ognyan Chernokozhev]

@rickytigg, @vattila In [r5928] I have implemented new options for switching the size unit convention between the Windows, IEC 80000-13 and metric.

Please review the changes and the new behavior and see if it is satisfactory, before I publish a new version of the tool.

[Ricky Tigg]

@jogybl |Code reviewing is a competence i don't have. I blindly trust the competence of your colleagues in this regard.

[Vidar Hasfjord]

@jogybl wrote:

Please review the changes and the new behavior and see if it is satisfactory, before I publish a new version of the tool.

I have now had a brief test and code review. Nice work! It seems to work well. However, I found some minor issues in the code, which I have fixed in [r5930], [r5931], [r5932], [r5933], [r5934] and [r5935]. So have a look, and make sure I have not made any regressions or unwanted changes.

Unfixed issue: The Up-Down controls in the Options dialog are limited to the range 0-100, and the buttons unfortunately work the other way around relative to expectations (pressing the up-button lowers the value, and vice-versa).

[Vidar Hasfjord]

Another issue: At the end of the scan, the status field is not updated to show the totals and times. However, committing the Options dialog will update the field as such.

PS. The totals could use some delimiters, as it gets confusing with the "Bytes only" setting, e.g. now: "Total size: 1,234,455 folders: 1323 files: 3455". For example, you could use vertical bar and capitalisation to better separate the fields: "Total size: 1,234,455 | Folders: 1323 | Files: 3455". Perhaps it would be even better with "bytes" as unit: "Total size: 1,234,455 bytes | Folders: 1323 | Files: 3455". And, by the way, the counts could use thousands separator as well, for consistency and readability: "Total size: 1,234,455 bytes | Folders: 1,323 | Files: 3,455".

[Vidar Hasfjord]

I've reviewed the latest fixes, and I found a few more issues:

• Totals and windows are not updated after "Rescan".
• Times in the display of totals should have space before units, i.e. "Times: 6722 ms 6957 ms", and ideally thousand separator, item separator and some explanatory text, e.g. "Times: 6,722 ms (background) | 6,957 ms (foreground)".
• When using the Up-Down controls in the Options dialog, the associated Edit control will show thousand-separator, e.g. "1,000", which is not parsed correctly by the dialog data transfer function, thus causing incorrect value conversion (e.g. 1 for "1,000") and possibly subsequent error message (e.g. "Large folders size much be greated than medium folder size").
• Spelling error "greated" in Option dialog error messages, e.g. see last point.
• File-local functions ConvertToUnits and ConvertFromUnits in "SettingsDlg.cpp" are obsolete and unused, and can hence be removed.