search

Shooter7119 / sequel-pro

Automatically exported from code.google.com/p/sequel-pro
Other
0 stars 0 forks source link

Import progress displays the wrong units for file size in Snow Leopard #690

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Import a large SQL file (>100MB makes the problem obvious)

What is the expected output? What do you see instead?
The "importing xxx of yyyMB" displays the file size in base-1024 units, rather 
than what's used by 
the OS (which, pre-SL, is the same; SL switched to base-1000).  My import file 
is 114,997,516B (OS 
displays 115MB), SP's progressbar says 109.7MB (114997516/1024/1024).

What version of Sequel Pro are you using? What version of MySQL are you
connecting to on the server?
r2224 on Snow Leopard 10.6.3

Original issue reported on code.google.com by firehed on 17 May 2010 at 11:14

GoogleCodeExporter commented 9 years ago

Original comment by stuart02 on 18 May 2010 at 9:41

GoogleCodeExporter commented 9 years ago 
Fixed in r2226 by changing the file size units to base 2 rather than base 10. 
Path provided by Max Lohrmann.

Original comment by stuart02 on 18 May 2010 at 8:04

GoogleCodeExporter commented 9 years ago 
Quick explanation:

Prior to 10.6 Apple (like everyone else) got this wrong. Apple had two 
possibilities to fix this and they decided 
to stay with the SI-Prefixes and make the transfer at 1000 in turn.
I believe this was mostly because of home users going "Hey I purchased a 1TB 
disk why does it only show 
950GB?" for years.

Sequel Pro on the other hand is a software for professionals and I think that 
for those the /1024 system is 
more important as it is used throughout console etc.

So we decided we will do the opposite of Apple and stay with the binary system 
but switch to the correct 
binary prefixes. SP will now be using KiB => Kibibyte, MiB => Mebibyte, GiB => 
Gibibyte and so on...

You have to start getting this right at some point :)

Original comment by schlabbe...@gmail.com on 18 May 2010 at 8:10

GoogleCodeExporter commented 9 years ago 
Sounds good to me - as long as it's correct and consistent :)

Original comment by firehed on 18 May 2010 at 8:14

GoogleCodeExporter commented 9 years ago 
I would like to re-open this issue. I think it's stupid to show different sizes 
from everybody else.

I fail to see why "professionals" would want 1024 over 1000, I think they don't 
care which one it uses as long as the same sizes are used everywhere. And right 
now, the sizes are different depending where you look (see screenshot).

In my opinion 1000 is the better size, since it is base-10 and we are using a 
base-10 number system. GiB and MiB only max sense if you are using HEX or some 
other number that multiplies well by 2. But most of all, I just wish sequel pro 
and finder displayed the same numbers.

Original comment by abhibeck...@gmail.com on 23 May 2013 at 2:18

Attachments:

GoogleCodeExporter commented 9 years ago 
When I said we'd have to do it right at some point I meant we have to decide on 
"1000B = 1KB" or "1024B = 1KiB" not the totally wrong and misleading "1024B = 1 
KB" as in the past.

I based my decision for base-2 on some factors:

- The IEC units were especially designed for representing sizes the way they 
are actually used by computers (meaning eg. that you can buy 512MB of RAM, not 
500MB and that Excel supports 256 columns, not 250 - limitations in computing 
usually grow in 2^x, not 10^x)
- I believe the decision to use SI units were purely an evil marketing trick 
used by hard disk vendors to upsell their products. While I appreciate that 
Apple decided to finally use a correct number+unit combination I've explained 
abvoe why I think they settled on SI units. As such I don't think we should 
support that marketing plot. 
- Interoperability: I work a lot on Linux and Solaris systems and they use IEC 
units. The same goes for Windows (though that still uses the wrong unit). I 
suspect a lot people that work with SQL databases also work on Linux systems, 
so that number would be more useful than a marketing number used only by HDD 
vendors and the Finder.

Original comment by schlabbe...@gmail.com on 23 May 2013 at 2:45