Closed Bug 637914 Opened 14 years ago Closed 14 years ago

Messages sizes are calculated in Kibibytes, but the UI says Kilobytes

Categories

(Thunderbird :: Folder and Message Lists, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: hugo, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b11) Gecko/20110209 Firefox/4.0b11 Build Identifier: Message sizes are calculated in Kibibytes, but the UI says Kilobytes. As stated on the International System of Units (the metric system), 1k = 1000, for any unit. 1kB = 1000B Since in computing, 1024 is used a lot, Kibibytes and Mebibytes where created; 1KiB = 1024B 1MiB = 1024*1024B Thunderbird uses the definition of Kibibytes for calculation, but the UI says Kilobytes. This results in the wrong data being presented to the user, with about 2% error margin for kilobytes, slightly more for megabytes, and notably more for gigabytes (~8%) And so on. Also note that "k" for Kilo is in lowercase, while Ki, for kibi is uppercase. (I previously mentioned this on comment 95 of 516787, which was the wrong place to do so) Reproducible: Always Steps to Reproduce: n/a Please see the following articles for more information: http://en.wikipedia.org/wiki/International_System_of_Units http://en.wikipedia.org/wiki/Kibibyte
As the person who implemented this, I will say that this was intentional, since it follows the behaviors of the default file explorers for every major OS/GUI toolkit except KDE 4's Dolphin. Windows Explorer, GNOME Nautilus, and (as far as I can tell) OS X's Finder all use KB = 1024 bytes.
This just shows there's a need to report a bug there as well, not imitate their broken behaviour. EVERY existing hard disk manufacturer uses 1MB = 1000000B. No exception. fdisk is the first example that comes to mind that uses 1kB = 1000B, or "Disk /dev/sdb1: 2000.4 GB, 2000397795328 bytes" I don't use much more software that uses either KB or KiB. "ls" rounds up too much. Imitating broken/non-standard behaviour won't help fix the issue really, just make the world more confusing. Besides, everyone knows 1K = 1000, just stand on a scale, and I'll say 1000kg, that doesn't mean you weigh 100*1024 grams
This is a dupe of bug 106618
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Those bugs are 10 years old, and was voted as "WONTFIX" because "nobody uses this". Times have changes, most people use this nowadays, it's common to see KiB everywhere, the standard was adopted, why do you opose this so much? The current UI would make me believe I'm using up more disk space than I really am, because it's use the WRONG UNITS!
>Times have changes They may have changed for you but not for me or most users. >it's common to see KiB everywhere I never saw it except in some linux distributions. >the standard was adopted The standard has been ignored for most software products.
You're contributing to the endless loop of: Some common software doesn't adopt <-> It's not THE SINGLE standard in the world? Currently, I have software that uses one measurement, and some that uses other. I end up trusting none, since it's hard to remember which is which (fdisk uses SI, and do drive manufacturer). In a world where EVERYONE uses the same, things get easier. Adopting standards contribute to this. Mozilla's products and Thunar are the only software products that I use that have not adopted these.
Matthias, it's not necessarily a dupe, because there's another option to solve this problem: calculate kilobytes as 1000 bytes instead of 1024. I agree that usage of binary prefices is uncommon, but it's also USELESS in most cases. What do you, as a user, gain from calculating data sizes in binary units? I don't see ANY gain in this at all. It's a common practice, yes, but it's a relic from the days when sizes of storage media was measured in dozens of MB, not in TB. My proposal is to keep using SI prefices, but calculate those amounts correctly instead.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
> My proposal is to keep using SI prefices, but calculate those amounts correctly > instead. Conversation and decision about this has been made i bug 637650. No need to have this in Core. Nothing prevents an extension from doing this
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → DUPLICATE
(In reply to comment #8) > > My proposal is to keep using SI prefices, but calculate those amounts correctly > > instead. > > Conversation and decision about this has been made i bug 637650. No need to > have this in Core. Nothing prevents an extension from doing this Sorry Ludo, but I don't see ANY discussion there regarding the use of REAL kB. It suggested using KiB instead of kB, and I can understand why Mozilla's developers are reluctant to do so. However, I've yet to see any arguments why calculating units using 1000 as a base is wrong, misleading and should be avoided or outsourced to an extension. I can start a new bug suggesting exactly that right from the start if you like (or if this comment will be ignored), but I think the title of this bug is pretty good already.
No operating system or utility that I know of measures the size of files in base-10 kB. The only examples I can think of that have ever used base-10 kB are unformatted hard drive sizes (fdisk is an example of this) and network speeds (though the latter is usually kilobits). I would certainly expect my mail client and my operating system to agree on the sizes of, say, attachments. That means using base-2 KB.
Jim, but why do you expect base-2 and not base-10 from both? I would think that the correct thing to do is to file bugs on those products that calculate sizes base-2. Perhaps it would be hard to convince Apple or Microsoft, but it should be easier with Linux. I don't think it would be too disrupting now, would it? On a more global scope, it would be much more convenient to calculate that 23,130,099,234,234 bytes is approximately 23.13 TB, without taking out a calculator and dividing that huge number by 1024 four times (which results in two TB less). Perhaps it's less of an issue to Americans (:D), but for metric system users, it's rather obvious.
In general, I figure the OS trumps individual applications ("when in Rome..."), so I'd have no problem changing this *after* the various operating systems did it, but not before. As far as how disruptive it is, I'd leave that call up to the OS developers. For what it's worth, a user or package manager can pretty easily modify the locale to use "KiB" if they think this is important (KDE systems might like that, since they use "KiB").
OSes have adopted this; the following is from my debian based computer, my GF's Ubuntu based one reports the same. My OpenBSD servers don't show the RX/TX in ifconfig. $ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:24:21:B7:C6:17 inet addr:192.168.0.108 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::224:21ff:feb7:c617/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:38889665 errors:0 dropped:0 overruns:0 frame:0 TX packets:20818930 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:57938000706 (53.9 GiB) TX bytes:1570620200 (1.4 GiB) Interrupt:45 Base address:0x6000 Acording to this discussion, Debian does the same thing as well: https://bugzilla.redhat.com/show_bug.cgi?id=118006 Note that, in the above discussion, it was never considered NOT to fix the bug, but rather (a) using base-10 for kB or (b) using base-2 for KiB. If "adopting what microsoft and apple" do is the policy, why support HTML5 in firefox, instead of "directx-based filters in CSS"?
(In reply to comment #13) > If "adopting what microsoft and apple" do is the policy, why support HTML5 in > firefox, instead of "directx-based filters in CSS"? That isn't the same comparison - the former is adopting similar UIs indications so that users can learn and expect the items are the same. The latter is a feature based subject which is totally different. Getting back on topic. All of the main graphical user interfaces (even it appears on Linux) use MB/KB at the same time as representing base-2. If we changed we would then have to explain to users why we are different and what the terms meant and why we're displaying the same number it in a different manner. This doesn't seem to be a worthwhile effort for us - if it came from all the major OSes, then yes we might do it, however at this time we're not going to do this -> Wontfix.
Resolution: DUPLICATE → WONTFIX
Debian, Fedora and Ubuntu don't seem like "major OS"? I wouldn't expect standard-compliance from microsoft if that's what you mean. At at the moment, you don't explain to anyone why it is at is is, cause it's hard to notice the sizes are calculated wrongly, but I guess if a great deal of people knew, they'd be **** by the fact that you purposely showed the wrong info.
You need to log in before you can comment on or make changes to this bug.