cross-posted from: https://discuss.tchncs.de/post/13814482
I just noticed that
ezacan now display total disk space used by directories!I think this is pretty cool. I wanted it for a long time.
There are other ways to get the information of course. But having it integrated with all the other options for listing directories is fab.
ezahas features like--git-awareness,--treedisplay, clickable--hyperlink, filetype--iconsand other display, permissions, dates, ownerships, and other stuff. being able to mash everything together in any arbitrary way which is useful is handy. And of course you can--sort=sizedocs:
--total-size show the size of a directory as the size of all files and directories inside (unix only)It also (optionally) color codes the information. Values measures in kb, mb, and gb are clear. Here is a screenshot to show that:
eza --long -h --total-size --sort=oldest --no-permissions --no-user
Of course it take a little while to load large directories so you will not want to use by default.
Looks like it was first implemented Oct 2023 with some fixes since then. (Changelog). PR #533 - feat: added recursive directory parser with `--total-size` flag by Xemptuous
No, @lseif@sopuli.xyz is correct.
I just did a test using
dd- I created 100 files of exactly 1 MiB each (1048576 bytes).dureported the size as "100M" as expected, whereasezareported it as "105M" - which is what you'd get if you divided 104857600 by 1000000 (= 104.8576 or 105M if you round it off).He is wrong, as I explained it multiple times that this is not the issue here. Install
ezaand compare toduand possibly some other application that reports the directory size. The difference in filesize cannot be explained by 1000 vs 1024 base. Do the math if you don't believe me.ezais reporting false directory size for me, unless there is an explanation.And for reference Dolphin the filemanager of KDE Plasma reports
149,1 MiB (156.366.443), which aligns withduwithout using--sioption. Even the one folder "target" is at183Mwitheza(which is the biggest folder in that directory anyway).I was talking about the 1000 vs 1024 issue, do the dd test yourself and it's easy to verify that he was right.
As for the specific descrepancy that you're seeing, lots of things can throw off a file size calculation - symlinks, sparse files, reflinks, compression etc. Since you're the only one with access to your files, you'll need to investigate and come to a conclusion yourself (and file a bug report if necessary).
Could it be this AND block size vs actual used size?