File size abbreviations is wrong

WinSCP 5.1 build 2625
Commander interface GUI
The file sizes are listed in "B", "KiB", "MiB"
I understand that "B" means bytes, and "KiB" is probably Kilobytes, although the common abbreviation is "Kb" or "kb".
What is "MiB"? Supposedly "Megabytes", but how did you manage to abbreviate it to MiB?
I don't have gigabyte files on my system, do you abbreviate their sizes to "GiB"?

The confusion comes from difference between decimal prefixes and binary prefixes, e.g., see
https://en.wikipedia.org/wiki/Byte#Multiple-byte_units

The major trouble is that Windows explorer only uses "kB" – "kO" in French – which is consistent with the k M G international scientific (ISO) unit abbreviation prefixes.

Please also note that Windows users are accustomed to "kB" only, not "MB".

This issue has been added to the tracker:
Issue 1123 – Revert to JEDEC size units instead of IEC units

@martin: I hope you didn't change from base-1024 to base-10 calculations, the latter being always meaningless and used only in marke*ing.

Explorer always used traditional symbols KB/MB in base-1024, and imo it should have stayed that way everywhere. Dunno why someone wanted to rename to KiB/MiB, creating an ever greater confusion. Previous confusion was caused exclusively by marketers (mostly on HD cases), but well-informed people always knew 1KB=1024bytes.

Ricardo wrote:

I hope you didn't change from base-1024 to base-10 calculations, the latter being always meaningless and used only in marke*ing.

Of course not. It's just about changing unit names.

Ricardo wrote:

<snip> change from base-1024 to base-10 calculations, the latter being always meaningless and used only in marke*ing.<snip>

I wonder... I am usually very keen on using the best units. I've switched in my personal life from US to metric and SI units, as much as possible. I have been irritated by the confusion twixt k=1024 and k=1000, and a worse error for MB and larger. I think that most folks would be just as happy if their computer systems reported file sizes in base 10, not base 2. I've been in the computer biz (software engineeer, embedded systems) for a few decades, and think freely in binary and hex, as well as Boolean algebra. Even so, I'd like one way to measure quantities, and that seems to me to be base 10. I /can/ see the use of other special units, such as KiB, for those who work exclusively in base 1024 blocks. I am not sure that most users of WinSCP and similar products are necessarily more comfortable in KiB than kB. Personally, I'd rather /know/ what the unit is, so if WinSCP is reporting in base 1024, then I appreciate not having to do the math myself, as I do in Windows. I really dislike Windows "under-reporting" file sizes. I'm constantly checking properties to see the "real" size. Nonetheless, I'd be just as happy if all file sizes are reported across all apps in base 10. I guess that is my vote.
~R~

Edit 2014-05-13. Here is a good example of the confusion I'd like to avoid. I just had to look at the size of a file, and Windows 7 Pro x64 Explorer reported it with THREE different values: 713 MB, 731017 KB, and 748 561 240 bytes. Go figure. I'd have been happy with 749 MB and 748561 kB. Those are SI units, any other social customs not withstanding, and values that I can readily relate to. While I recognize that there are those who need to measure such things in base 2, I don't get any added value by seeing the base 2 "megabytes".

As an aside, I wish that the SI folks had decided that all postive base-10 exponents would be CAPs and negative exponents lc: KB and ms, for example, but that is another forum.
~R~

Ninetrees wrote:

I'm constantly checking properties to see the "real" size. Nonetheless, I'd be just as happy if all file sizes are reported across all apps in base 10.

I wouldn't mind. But industry standard atm is to use base-2 sizes, so does WinSCP.

@martin: I don't know what the "industry" is nor do I know who their "customers" are. I don't mean that as rudely as it sounds, sorry. But I don't. Who really thinks that base 2 is more comprehensible than base-10?

I recall a survey back in the 1980s (yep, I've been a software engineer that long) about programming langauges. The overwhelming "favorite" compiler was C. Because I supervised a large technical software engineering department, I was interviewed after the article came out to see how we felt about it. I suggested that the article was off track, and suggested the author run another survey, and this time ask what language most folks programmed in. This time the answer was Pascal. So the journal ran /that/, and asked the question "If your favorite language is C, why do you do most of your programming in Pascal?" The answer was that the favorite language was C because respondents, reading various trade journals, thought that C was the "in" language (because that's what journals published), and /should/ be their "favorite", despite the fact that it was arcane and inadquate at the time. You see the point? Programmers chatted up C because they thought it was "cool" and "in", and then trade journals reported that C was "cool" and "in", and folks read those journals and thought that C was "cool" and "in", and...

So who is driving this boat?

In a country (US) that is resisting going to metric in general and SI specifically, I moved to SI for the sense of it and for the convenience. Yep. Down in my woodshop, I build all my projects in SI. I measure my cycling performance in SI. I use the 24 hour clock. Women in this country now know that mascara product X will make their lashes 4 mm longer... my mountain bike dimensions are all metric... but my file sizes are reported in base 2.

I work in a technical field, not primarily software engineering, but we use software extensively to solve scientific and engineering problems. I'll bet that if I asked 100 coworkers how much a MiB is, I'd be lucky to get 1 correct answer. And those are technical folks. If I surveyed 100 computer users in the area, I'd be surprised to get any correct answers. So while I can think in binary and hex and Boolean algebra, I am in a very small minority, AFAIK.

In closing, I understand that this is just my opinion and perspective. I may simply not be seeing the vast number of users who prefer their file sizes reported in base 2 because base 2 provides them with information that base 10 does not. I do get to hear the whining complaints of those who are frustrated with not knowing why that 1 GiB file won't fit in the 1 GB of file space left on that USB drive.

I promise not beat this up any more ;-) Not here. Maybe with MS ;-) I appreciate knowing that you read the earlier post and responded.

~R~

Well "industry" in this sense may simply mean "Microsoft". We try to make WinSCP integrate seamlessly to Windows. So when Windows Explorer shows that a file has 156789 KB, we need WinSCP to show the same file as having 156789 KB, not 153114 KB or anything else. It's as simple as that :) That does not mean I object in any sense to what you have written.

As a programmer myself I often have to add UI changes for my users that I would never myself use. This may be one of those cases.

With a system default setting and an override possible on a connection by connection basis perhaps add a preference of how to display the values in the UI. And I can think of two ways to do this. The first might be the easiest. Just have 4 different data columns available for the UI that can be enabled or disabled individually and each one shows the size in a different system. Those columns would be "System Default Units" (KB in Windows I think), "Bytes" (if our file is 1,234,567,890 bytes long then that is what it shows - with the preferred separator for your region 1.234.567.890 in Europe for instance or 1,23,45,67,890 in India), KB/KiB (1024 bytes per K), kB (1000 bytes per k). And an option to auto scale from K to M to G to P as needed. With those columns all predefined you could even show all of them side-by-side.

Or just have the settings in the config as something like SizeDisplayMode=[1,2,3,4] and SizeDisplayAutoScale=[0,1] and then the size column would just display as your preference indicates.

More options means more code to maintain and more documentation, but you also get more flexibility.

Just my 2 cents worth.

@Freitag: Thanks for your suggestion. Let's see what demand for this would be.