GNOME Bugzilla – Bug 665005
Nautilus 3.2.1 Displays "Wrong" Filesizes Compared to All Other Programs & Websites (Decimal vs Binary)
Last modified: 2012-06-25 21:30:53 UTC
OK, first off, I know this has to do with the Mb vs MiB issue, ie is a megabyte 1000k or 1024k?, and this could possibly have more to do with Ubuntu's "unit policy" moving from base-2/Binary to base-10/Decimal in 11.10. HOWEVER, and that's a big "however", every single program on my system besides Nautilus still displays filesizes as I've been used to seeing them since the early '90s (ie: binary), which is great, as every single web site I visit also does the same. So while I don't really think this is a "bug" in the purest sense, to me it is as annoying as one, not just because (for example) sizes of downloaded files differ from the info on the site they came from, but because - and I'm not the only one to encounter this - this situation has caused some anomalies, like disc images failing to burn because the 700Mb (or MiB, or whatever) ISO is now 730Mb. If Nautilus was just another app, I could probably learn to deal with it, but this is Ubuntu's file manager, which is a pretty big deal. So is there any config file hack I can implement to change display of filesizes back to base-2? Are there plans for Nautilus to have the choice between decimal and binary (or even a third choice, to display both, as in "(1.50 TB/1.36 TiB)")?
You failed to actually mention what Nautilus currently does, and where (steps to reproduce). AFAIK g_format_size_for_display() always return base 2 units; and Nautilus is a direct consumer of this API.
Sorry, I thought the problem was obvious, so I'll explain: 1) Open Nautilus 2) Select a file 3) Watch the filesize be wildly different from what any other file manager says, and if I had an earlier version of Ubuntu with a 2.x Nautilus, that would show a different size from 3.2.1 as well. From what I am reading out there, this is pretty common, and since there doesn't seem to be a hack or fix, people like myself have been urged by others to file this as a "bug report". While some aren't too bothered, for others like myself this is one of the worst "bugs" ever, since I either need a binary/decimal calculator, or try doing it in my head (why bother, you ask? A 350Mb file might appear to have downloaded OK, with Nautilus saying it is 365Mb, but in fact could be a few Mb short, so actually a failed download, yet I can't see that, whereas before if I saw it say 348Mb I'd know it failed).
PS: I'd love to blame this on the Ubuntu unit policy, but seems plenty of users of other distros are experiencing this, with the common denominator being Gnome 3/Nautilus 3.x. And at least once saw mention of Nautilus 3.x deliberately being this way, ie that the Nautilus developers decided it was time to go base-10. Not sure about all that - just sure that this is one of the most bothersome things since I start using Linux in 2006. I'm already finding I'm opening Thunar a hell of a lot just to see the correct sizes - eventually, I might not see any reason to continue using Nautilus.
I'm responsible for this change. There is an extensive discussion in bug 554172. I used to agree with your point of view and I was rather against power-of-10 sizing, but it's becoming increasingly difficult to defend that position. First: using KB to mean "1024 bytes" is completely indefensible (since there is no such prefix as "K"). Using MB to mean "1024 * 1024 bytes" is a downright lie (since "M" means something else entirely: one million). Either of these are completely out of the question. This was our previous behaviour and it was very wrong. So the question comes down to using "KiB" to mean 1024 or "kB" to mean 1000. That's a legitimate debate, but it's clear which way the wind is blowing on this one. Everyone who sells any kind of disk has switched to using base-10 units. Download speeds are also reported in base 10 units (and always have been). The only thing that's still in powers of 2 anymore is RAM, and Nautilus doesn't normally report the size of objects in memory... Add to that the simple fact that base-10 units make more sense to the vast majority of humans. The API introduced in GLib actually supports power-of-2 sizes, with the correct units written. Nautilus is electing not to use this feature (and correctly, in my opinion). I suggest you report bugs against the software in which you spot the inconsistencies. As noted, it's in violation of Ubuntu's unit policy, so Ubuntu should be patching that other software, at least. I feel our previous behaviour (although I was originally in support of it) was a bug. Our change of behaviour is, in my opinion, correct and well-reasoned. The change has also received a lot of positive feedback. There is, therefore, no chance that we will revert this change. fwiw, I expect that Thunar will follow suit soon...
Thanks for that info. At least I can tell people to stop blaming Ubuntu (and other distros). Hey, I do hear ya on this, BUT the fact that websites have not followed suit is a major worry. I just feel that while it all might be going decimal, this is way too premature, pretty much because hardly any web site out there lists their files in base-10. As for disc/flash/drive manufacturers... I might be wrong, but it's not like they "switched" to base-10, but actually started the trend. As far as I can remember, in every other aspect of computing, base-2 ruled... so it seems computers (and hopefully eventually websites) are made to fall in line with the scam advertising of consumable makers, hehe. Back to what I see as prematurity about this change, just pointing out again that currently Nautilus is the only program on my entire system to use those units. Even Linux commands like du still use binary. So please forgive all the users who are less than impressed with this.
*** Bug 660661 has been marked as a duplicate of this bug. ***
ARGH :-((( Not configurable :-(( Strongly disagree with the download-speed numbers. They have always been in bits, not in bytes, and that is the much bigger difference.