Created attachment 4698 Screeon Shot Comparsion between Dolphin and Thunar FM Respect Sir, While checking the size of a folder or an application in Thunar File Manager, it size is displayed in bytes and it not convert into GB. Error -Example File Size 1457892152bytes = 1.45GB Actual -Example File Size 1457892152bytes = 1.35GB The bug that is beening reported is a minor. But many havenot noticed it. Well there is an Picture attachment which is an comparision with dolphin file manager.
And what is the output of "du -csh /home/kris"?
I confirm the problem, but it is a matter of interpretation. I wonder if the units are used consistently though (Job window, properties window, status bar,...). GB, MB, KB is older standard (and now should be used for sizes of 1000) and nowadays GiB, MiB, KiB should be used (sizes of 1024). This can be read up on http://en.wikipedia.org/wiki/KiB, if you don't like wikipedia there certainly are better sources explaining this. Look at the screenshot to see how Dolphin deals with it. The netload plugin uses KiB, MiB etc. too. BTW: du -sh is different from thunar's value: ls -la file: 6138497316 file du -sh file (German locale): 5,8G thunar file (German locale): 6,1 GB (6.138.497.316 Bytes) Seems to be in thousands, not 1024.
1.4 was optimistic because it also counted the directory metadata size (4K), I've fixed this in 1.5. The code uses 1000 by default (byte/kB/MB/..) not 1024 (KiB, MiB). See the comment in the glib manual: G_FORMAT_SIZE_IEC_UNITS: use IEC (base 1024) units with "KiB"-style suffixes. IEC units should only be used for reporting things with a strong "power of 2" basis, like RAM sizes or RAID stripe sizes. Network and storage sizes should be reported in the normal SI units.
Btw, there is also a difference in disk size and real file size, we use the latter since it give more relevant sizes intendant from the fs-layout.
I see, didn't know about that. Probably one will get accustomed to that, though it will certainly cause confusion with the rest of the (command-line) tools reporting different sizes.
If tested this a bit and it works fine for me. du shows the same sizes most in most situation, so I consider this a minor issue.
Of course it works. The question is not if this is a minor issue or a big one, but whether you consider this an issue at all. Manufacturers use decimal units (1000) for advertising their products. Internet providers measure speed in decimal units because it looks better. But software has always shown these numbers in powers of 2. This confuses users who are not much acquainted with computers, e.g. a 4 GB USB stick would appear to be only 3.9GiB in size. Using units of 1000 instead of 1024 makes the sizes comparable to the numbers advertised. In your case, du shows the same sizes because your numbers have not been high enough to make much difference. The more the numbers increase, the higher the difference will be. From this point of view, it may be a minor issue now, but could be a noticable issue in a few years (or is already, when you're lucky and get the chance to deal with such big storage sizes). Approximate differences decimal / binary in %: kB <> KiB: 2.40% MB <> MiB: 4.86% GB <> GiB: 7.37% TB <> TiB: 9.95% PB <> PiB: 12.6% However, I believe the glib idea was not to be compatible with command-line tools, but to offer an easier approach for the user. On the one hand, using decimal units ensures you don't have to explain why a device provides less space than advertised. On the other hand, I'm sure any poweruser or administrator who is used to the binary system will likely freak out. If it needs to be 'fixed', then it should be as easy as passing a flag to that glib format function IIRC (and update the unit strings). If not, you simply need to get used to the difference.
Created attachment 4733 use-binary-units-instead-of-decimal-units.patch For anyone who needs it, this quick patch makes thunar show sizes in binary units.