After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 550100 - gio uses 10^3 base (SI) for volume names
gio uses 10^3 base (SI) for volume names
Status: RESOLVED OBSOLETE
Product: gvfs
Classification: Core
Component: [obsolete] hal volume monitor
unspecified
Other All
: Normal minor
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2008-08-31 18:50 UTC by Pierre Ossman
Modified: 2016-10-19 13:43 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
[PATCH] Use g_format_size_for_display for consistency. Bug #550100. (1.86 KB, patch)
2008-08-31 19:49 UTC, Christian Persch
rejected Details | Review

Description Pierre Ossman 2008-08-31 18:50:25 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:
Comment 1 Christian Persch 2008-08-31 19:46:23 UTC
-> 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.
Comment 2 Christian Persch 2008-08-31 19:49:14 UTC
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(-)
Comment 3 Christian Kellner 2008-09-01 10:53:32 UTC
Agreed. Committed. Lots of thanks, Mr Coding Machine Christian Persch! ;-)
Comment 4 David Zeuthen (not reading bugmail) 2008-09-02 18:12:23 UTC
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.
Comment 5 David Zeuthen (not reading bugmail) 2008-09-02 18:15:07 UTC
(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".
Comment 6 David Zeuthen (not reading bugmail) 2008-09-02 18:20:23 UTC
Patch reverted.
Comment 7 David Zeuthen (not reading bugmail) 2008-09-02 18:20:52 UTC
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".

Comment 8 Christian Persch 2008-09-02 18:26:25 UTC
(Btw, the patch does not use the "nerd units" KiB/MiB/etc since g_format_size_for_display uses the normal kB, MB, etc.)

Comment 9 Pierre Ossman 2008-09-02 18:30:47 UTC
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.
Comment 10 David Zeuthen (not reading bugmail) 2008-09-02 18:36:41 UTC
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().
 **/
Comment 11 David Zeuthen (not reading bugmail) 2008-09-02 18:45:24 UTC
(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.
Comment 12 Christian Persch 2008-09-02 18:53:30 UTC
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.
Comment 13 David Zeuthen (not reading bugmail) 2008-09-02 19:00:46 UTC
(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.
Comment 14 Christian Neumair 2008-09-03 11:12:16 UTC
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.
Comment 15 David Zeuthen (not reading bugmail) 2008-09-03 14:56:18 UTC
(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
Comment 16 Christian Neumair 2008-09-03 15:31:34 UTC
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.
Comment 17 Matthias Clasen 2008-09-03 15:42:25 UTC
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
Comment 18 David Zeuthen (not reading bugmail) 2008-09-03 15:44:36 UTC
(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.
Comment 19 Christian Neumair 2008-09-03 16:05:46 UTC
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.
Comment 20 Tor Lillqvist 2008-09-03 16:11:00 UTC
> 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.
Comment 21 Pierre Ossman 2008-09-03 16:19:22 UTC
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.
Comment 22 David Zeuthen (not reading bugmail) 2008-09-03 16:32:06 UTC
(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.
Comment 23 David Zeuthen (not reading bugmail) 2008-09-03 16:34:56 UTC
(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.

Comment 24 David Zeuthen (not reading bugmail) 2008-09-03 16:40:08 UTC
(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)

Comment 25 Pierre Ossman 2008-09-03 16:44:58 UTC
(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.
Comment 26 David Zeuthen (not reading bugmail) 2008-09-03 16:57:11 UTC
(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.
Comment 27 Ondra Pelech 2009-04-25 17:01:21 UTC
I've filled a bug on the HIG regarding to this stuff.

http://bugzilla.gnome.org/show_bug.cgi?id=580232
Comment 28 Ondrej Holy 2016-10-19 13:43:53 UTC
Hal volume is obsolete currently. If you see this issue also with udisks2 volume monitor, please file a bug for udisks2 volume monitor...