GNOME Bugzilla – Bug 550100
gio uses 10^3 base (SI) for volume names
Last modified: 2016-10-19 13:43:53 UTC
GIO computes disk sizes using 10^3 when it names volumes without a label. This is inconsistent with the rest of the environment which uses classical 2^10 calculations. E.g. if I open the properties window on my SD card, I see that my "495.3 MB Media" has a capacity of "472.2 MB" Other information:
-> gvfs. ghalvolume.c uses 1000 while g_format_size_for_display uses 1024. It might be that this was intentional, but it should probably just use g_format_size_for_display. Here's a patch doing that.
Created attachment 117713 [details] [review] [PATCH] Use g_format_size_for_display for consistency. Bug #550100. monitor/hal/ghalvolume.c | 33 ++------------------------------- 1 files changed, 2 insertions(+), 31 deletions(-)
Agreed. Committed. Lots of thanks, Mr Coding Machine Christian Persch! ;-)
No, there's a reason we're not using the nerd units which I'm not going to go into here. The patch should be reverted.
(In reply to comment #4) > No, there's a reason we're not using the nerd units which I'm not going to go > into here. Someone on IRC asked why: the main reason is that drive + media manufacturs use powers of 10. So we want to display e.g. "64M Volume" not "61.7MB Volume".
Patch reverted.
2008-09-02 David Zeuthen <davidz@redhat.com> * monitor/hal/ghalvolume.c (do_update_from_hal): Revert patch from bug 550100 - we really don't want to show "61.7MB Volume" instead of "64M Volume".
(Btw, the patch does not use the "nerd units" KiB/MiB/etc since g_format_size_for_display uses the normal kB, MB, etc.)
What about all the other countless places that do not use the marketing version? They are in a majority by a wide margin. Having different values at different places is worse than any inconsistency the user has between what's printed on the box and what shows up.
FWIW, I've added the rationale in the sources - including ideas on how to use quirks for troublesome media. /** * format_size_for_display: * @size: a number of octects * * Format a human readable string that can conveys how much storage a * user-visible drive or piece of media can hold. * * As a matter of policy, we want this string to resemble what's on * the packaging of the drive/media. Since all manufacturers use * powers of 10, g_format_size_for_display() is not suitable here. * * TODO: we probably want to round to nearest power of two if @size is * "close" (e.g. within 5%) - this is to avoid e.g. 63.4G when the * packaging says "64G drive". We could also use per-drive or * per-media quirks to make a better guess. * * Returns: A human readable string, caller must free it using * g_free(). **/
(In reply to comment #9) > What about all the other countless places that do not use the marketing > version? They are in a majority by a wide margin. [Citation needed] Honestly, for the desktop shell I can only think of the status bar in Nautilus indicating the free space. And, FWIW, I'd argue that's a bug in Nautilus. Besides, I'd argue the difference by seeing the label "200GB Volume" and seeing that it has 186GB free (if it's empty) is well understood. Even so, Nautilus should just be fixed. However, IMNSHO, what is a bug, is displaying "186G Volume" to the user when he just hotplugged an external disk that has "200G Super Duper Disk" in the packaging. That's just confusing. FWIW, this discussion has happened many times before. I consider trying to sneak in patches like this pretty bad form.
I resent the accusation that I was trying to 'sneak in' that patch. I merely noticed the bug, moved it to the correct component and provided a patch for what I considered a simple oversight. And the patch was accepted and committed by a *gvfs developer*, not by me. Now that there's been an explanation, I even agree that the labelling done by gvfs is correct here.
(In reply to comment #12) > I resent the accusation that I was trying to 'sneak in' that patch. Sorry about that, I was out of line with that comment - I instantly, because there's so much history about this topic, assume malice which was wrong. Sorry again.
I totally love base 10 units. But wouldn't the most flexible and solomonic approach be to use g_format_size_for_display(), and add a preference/environment variable whether you want base K=10^3 or K=1024? I'd love if it defaulted to K=1000.
(In reply to comment #14) > But wouldn't the most flexible and solomonic approach be to use > g_format_size_for_display(), and add a preference/environment variable whether > you want base K=10^3 or K=1024? I'd love if it defaulted to K=1000. When g_format_size_for_display() was added I complained about it hard coding K=1024: http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00238.html with replies like "oh big deal" etc etc http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00246.html
I commented on the thread, since I am convinced that it is worth further discussion: http://mail.gnome.org/archives/gtk-devel-list/2008-September/msg00017.html I am reopening this bug report, so that it doesn't get lost.
I don't think a user preference is necessarilyt right here, since this seems to be essentially two different use cases, after all: - displaying the 'nominal/manufacturer-advertised' size of a volume/device, more or less part of the name - displaying the 'actual' free space or file size of a file/filesystem
(In reply to comment #17) > I don't think a user preference is necessarilyt right here, since this seems to > be essentially two different use cases, after all: > > - displaying the 'nominal/manufacturer-advertised' size of a volume/device, > more > or less part of the name > > - displaying the 'actual' free space or file size of a file/filesystem > Yeah, I think I agree. Also, as noted in comment 11 I think it's well understood that these numbers differ. FWIW, I think initially I used strings of the form "200G Volume" instead of "200GB Volume" to make that clear. Maybe we should go back to that.
re comment 11: > Besides, I'd argue the difference by seeing the label "200GB Volume" and seeing > that it has 186GB free (if it's empty) is well understood. <sarcasm> Oh yeah, now that you explained it, it is totally intuitive. Even my grandmather grasped it if she was still alive. </sarcasm> I don't consider it well-understood that various parts of the desktop count file(system) sizes differently, and I have to double-check it each time. Why can't we have ONE environment variable that's picked up by every *NIX citizen from file system tools to download managers, that defines how this is handled? That's what I call consistency.
> the nerd units Sorry, but I would say that it's the kibi, mebi, gebi etc prefixes that are the "nerd" ones. > Since all manufacturers use powers of 10, Note that at least so far, flash media manufacturers use the G = 1073741824 convention, though. You can buy 32 GB memory cards, not 34 GB ones. Maybe once they start offering capacities that are not exact powers of two (is that possible, technically?) they will slip into the decimal camp, though.
In case someone is counting, my vote is for 2^10 units (obviously). David, I understand your position but I don't believe that the solution to the vendors lying (yes, I'd consider it lying to go against all accepted norms even if you are technically correct) is to keep on lying to the user. The size is not just an arbitrary number, so it is important that it is correct even when used as a name for the volume. Have you thought anything about naming it using other things than the size? (In reply to comment #20) > > Note that at least so far, flash media manufacturers use the G = 1073741824 > convention, though. You can buy 32 GB memory cards, not 34 GB ones. Maybe once > they start offering capacities that are not exact powers of two (is that > possible, technically?) they will slip into the decimal camp, though. > I hate to burst your bubble, but I have a bunch of USB devices and SD cards that show that those vendors are just as devious. And the storage there is not exact powers of two as you have some overhead for the wear leveling.
(In reply to comment #21) > The size is not just an arbitrary number, so it is important that it is correct > even when used as a name for the volume. Have you thought anything about naming > it using other things than the size? Sure, if there's a file system label or other quirks (such as if it's a music player) we use a name derived from that. > I hate to burst your bubble, but I have a bunch of USB devices and SD cards > that show that those vendors are just as devious. So we just quirk it for some devices. The end goal, which should be kept in mind, is to ensure that the _icon_ name (in absence of file system labels etc) matches what's on the packaging of the drive/media. > And the storage there is not > exact powers of two as you have some overhead for the wear leveling. Might be off-topic to comment on this but I believe (at least for some devices) that storage set aside for wear leveling isn't exposed to (at least) user space.
(In reply to comment #20) > > the nerd units > > Sorry, but I would say that it's the kibi, mebi, gebi etc prefixes that are the > "nerd" ones. I didn't express myself very well here; what I meant was that it's nerdy to show "61.7MB Volume" for the _icon name_ (instead of e.g. "61M Volume") just because of someone (e.g. nerds) insists on using powers of 2, user experience be damned. > > Since all manufacturers use powers of 10, > > Note that at least so far, flash media manufacturers use the G = 1073741824 > convention, though. You can buy 32 GB memory cards, not 34 GB ones. Maybe once > they start offering capacities that are not exact powers of two (is that > possible, technically?) they will slip into the decimal camp, though. So we quirk it and fix things up cf. the TODO in comment 10.
(In reply to comment #19) > Why > can't we have ONE environment variable that's picked up by every *NIX citizen > from file system tools to download managers, that defines how this is handled? > That's what I call consistency. Kinda off topic, but keep in mind that environment variables generally isn't a good solution; it means you can't dynamically change the preference you want express. You want to use XSettings here, but unfortunately we can't do that from glib. One solution to this is to use a GIOExtensionPoint in g_format_size_for_display() and a GIOExtension for said extension point provided by e.g. gtk+. Unfortunately we can't use gio from raw glib so that won't work either (which definitely, IMHO, is something to fix for glib 3.0)
(In reply to comment #22) > (In reply to comment #21) > > The size is not just an arbitrary number, so it is important that it is correct > > even when used as a name for the volume. Have you thought anything about naming > > it using other things than the size? > > Sure, if there's a file system label or other quirks (such as if it's a music > player) we use a name derived from that. > Yeah, but if we stick to the "has no label" scenario; what other pieces of information are there? In most cases I see a vendor and model name in the hal tree. Couldn't something be constructed using those instead? > > So we just quirk it for some devices. The end goal, which should be kept in > mind, is to ensure that the _icon_ name (in absence of file system labels etc) > matches what's on the packaging of the drive/media. > On my USB sticks, the model name is far more prominent than the storage size. > > And the storage there is not > > exact powers of two as you have some overhead for the wear leveling. > > Might be off-topic to comment on this but I believe (at least for some devices) > that storage set aside for wear leveling isn't exposed to (at least) user > space. > Yeah, my point was really that even if the underlying low level flash is some power-of-two size, the wear leveling always fudges things to something more arbitrary.
(In reply to comment #25) > Yeah, but if we stick to the "has no label" scenario; what other pieces of > information are there? In most cases I see a vendor and model name in the hal > tree. Couldn't something be constructed using those instead? Maybe. There's as many opinions on how to select the icon names (and icons!) for drives/media as there's people. One problem is that vendor/product strings aren't localized. Another is that you'd need to fix them up (some are all upper case). And some contain lots of scary long numbers and useless information, e.g. vendor=ATA model=ST9100821AS So the main reason we generally use vendor/model names is that it's completely inconsistent what the vendor/model fields look like. Besides, it's hard to handle if there are multiple partitions, do you use "ATA ST9100821AS 42GB Volume" It's a can of worms; FWIW, I've spent a lot of time trying to think about how to do this. > On my USB sticks, the model name is far more prominent than the storage size. It's my experience that users actually relate more to - the size of the device ("my 40GB USB hard disk"); and - how it is connected (hence why we use a connection specific icon); or - the media type if media is removable (hence we why have e.g. SD and CF icons) than - the actual make and model ("my hard disk from vendor XYZ"). That's another reason we avoid using vendor/model.
I've filled a bug on the HIG regarding to this stuff. http://bugzilla.gnome.org/show_bug.cgi?id=580232
Hal volume is obsolete currently. If you see this issue also with udisks2 volume monitor, please file a bug for udisks2 volume monitor...