[tor-bugs] #12909 [Stem]: stem.util.str_tools.get_size_label() insufficiently precise

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#12909: stem.util.str_tools.get_size_label() insufficiently precise
--------------------+------------------------
 Reporter:  mmcc    |          Owner:  atagar
     Type:  defect  |         Status:  new
 Priority:  normal  |      Milestone:
Component:  Stem    |        Version:
 Keywords:          |  Actual Points:
Parent ID:          |         Points:
--------------------+------------------------
 There is a known issue in Arm that causes AccountingMax sizes to be
 displayed with insufficient precision. For example, a real AccountingMax
 of 1850 GB will be displayed as 1 TB.

 https://trac.torproject.org/projects/tor/ticket/12452

 This is confusing and perplexing, especially for those worried about big
 bandwidth overage charges.

 It seems that this is an issue with
 `stem.util.str_tools.get_size_label()`, which is itself mostly a wrapper
 for `stem.util.str_tools._get_label()`. These functions format and return
 the string that is then displayed:


 (the call in arm)

 https://gitweb.torproject.org/arm.git/blob/ac7923e31f52d3cf51b538ddf799162d67c04ecc:/arm/graphing/bandwidth_stats.py#l504

 (the called Stem function)

 https://gitweb.torproject.org/stem.git/blob/6c78d9acf9606eb6a93712cfe115a40c45504c70:/stem/util/str_tools.py#l134

 Here's the above example problem returned from the master branch of Stem
 (version 0.1.2.3, I believe), cloned on 20-08-2014. 1850000000000 is 1850
 GB converted to bytes:

 {{{
 >>> from stem.util.str_tools import get_size_label
 >>> get_size_label(1850000000000)
 '1 TB'
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12909>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs