linuxPIPEpower

Nice! I'm sure they will appreciate your thorough report.

I wonder if they also plan to make an option about crossing filesystem boundaries. I have seen it commonly in this sort of use case.

Maybe all this complexity this is the reason why total dir size has not previously been integrated into this kind of tool. (Notable exception: lsd if you are interested.) I really hope the development persists though because being able to easily manipulate so many different kinds of information about the filesystem without spending hours/days/weeks/years creating bespoke shell scripts is super handy.

I am inclined to agree with you. See my comment in cross post of this thread.

I'm just a home admin of my own local systems and while I try to avoid doing stuff that's too wacky, in the context I don't mind playing a bit fast n loose. If I screw it up, the consequences are my own.

At work, I am an end user of systems with much higher grade of importance to lots of people. I would not be impressed to learn there was a bunch of novel bleeding edge stuff running on those systems. Administering them has a higher burden of care and responsibility and I expect the people in charge to apply more scrutiny. If it's screwed up, the consequences are on a lot of people with no agency over the situation.

Just like other things done at small vs large scale. Most people with long hair don't wear a hairnet when cooking at home, although it is a requirement in some industrial food prep situations. Most home fridges don't have strict rules about how to store different kinds of foods to avoid cross contamination, nor do they have a thermometer which is checked regularly and logged to show the food is being stored appropriately. Although this needs to be done in a professional context. Pressures, risks and consequences are different.

To summarize: I certainly hope sysadmins aren't on here installing every doohicky some dumbass like me suggests on their production systems. :D

Some of the distros actually just included an alias from exa to eza when the project forked. I didn't even realize I was using eza for a long time!

ooops you commented similar/same twice. I think this one was a draft. :)

For my part I think all this troublefinding and troublesolving is a great use of a thread. :D Especially if it gets turned into a bug report and eventually PR. I had a quick look in the repo and I don't see anything relevant but it could be hidden where I can't see it. Since you've already gone and found the problem it would be a shame to leave it here where it'll never be found or seen. Hope you will send to them.

I also reproduce the bug by moving an ISO file into a directory then hardlinking it in the same dir. Each file is counted individually and the dir is 2x the size it should be! I can't find any way to fix it.

The best I can come up with is to show the links but it only works when you look at the linked file itself:

$ eza --long -h --total-size --sort=oldest --no-permissions --no-user --no-time --tree --links LinuxISOs
Links Size Name
    1 3.1G LinuxISOs
    2 1.5G ├── linux.iso
    2 1.5G └── morelinux.iso

If you look further up the filetree you could never guess. (I will say again that my distro is not up to date with the latest release and it is possible this is already fixed.)

This should be an option. In dua-cli, another one of the other rust terminal tools I love, you can choose:

$ dua  LinuxISOs
      0   B morelinux.iso
   1.43 GiB linux.iso
   1.43 GiB total

$ dua --count-hard-links LinuxISOs
   1.43 GiB linux.iso
   1.43 GiB morelinux.iso
   2.86 GiB total

well I guess a way to test would be to create a new directory and copy or create some files into it rather than using a working directory where there are unknown complexities. IIRC dd can create files according to parameters.

Start with a single file in a normal location and see how to get it to output the correct info and complicate things until you can find out where it breaks.

That's what I would do, but maybe a dev would have a more sophisticated method. Might be worth while to read the PR where the feature was introduced.

Also kind of a shot in the dark but do you have an ext4 filesystem? I have been dabbling with btrfs lately and it leads to some strange behaviors. Like some problems with rsync. Ideally this tool would be working properly for all use cases but it's new so perhaps the testing would be helpful. I also noticed that this feature is unix only. I didn't read about why.

it would be that du AND Dolphin filemanager would ignore those files, and eza would not. Which its hard to believe for me.

Although only 1 of various potential causes, I don't think it is implausible on its face. du probably doesn't know about git at all right? If nautilus has a VCS extension installed I doubt it would specifically ignore for the purposes of calculating file size.

I have found a lot of these rust alternatives ignore .git and other files a little too aggressively for my taste. Both fd (find), and ag (grep) require 1-2 arguments to include dotfiles, git-ignored and other files. There are other defaults that I suppose make lots of sense in certain contexts. Often I can't find something I know is there and eventually it turns out it's being ignored somehow.

why not just add the options to it?

If you are asking me, personally, it's because making any contributions to ls is far beyond my capacities and will remain that way for the forseeable future.

Personal deficiencies aside, would it even be a good idea to modify ls in this way? It seems to me that stability and predictability is a feature, not a bug. Basically you know how ls will work on every linux system. Adding all these features would turn it into something else and potentially introduce chaos. ls is tested on >millions of systems in every context; a known quantity. A feature set which is limited to the necessities avoids introducing bugs, flaws, security issues etc.

And once added, a feature probably shouldn't be removed. In 2024 I love having git status optionally integrated into my ls-type tool. But in 2034 will git still be as ubiquitous? What about 2054? ls is for the ages. eza is for right now.

aside from the subject of the post: the ones I miss when it's not available are git status/ignoring, icons, tree, excellent color coding.

Here I cloned the eza repo and made some random changes.

eza --long -h --no-user --no-time --almost-all --git --sort=date --reverse --icons

Made some more changes and then combine git and tree, something I find is super helpful for overview:

eza --long -h --no-user --no-time --git --sort=date --reverse --icons --tree --level=2 --git-ignore --no-permissions --no-filesize

(weird icons are my fault for not setting up fonts properly in the terminal.)

Colors all over the place are an innovation that has enabled me to use the terminal really at all. I truly struggle when I need to use b&w or less colorful environments. I will almost always install eza on any device even something that needs to be lean. It's not just pretty and splashy but it helps me correctly comprehend the information.

I'd never want to get rid of ls and I don't personally alias it to to eza because I always want to have unimpeded access to the standard tooling. But I appreciate having a few options to do the same task in slightly different ways. And it's so nice to have all the options together in one application rather than needing a bunch of scripts and aliases and configurations. I don't think it does anything that's otherwise impossible but to get on with life it is helpful.

hmm I didn't think to actually test the results. But now that i do, I get same sort of descrepency.

How about this?

eza --long -h --total-size --sort=size --no-permissions --no-user --no-time -a --blocksize --binary

that works in a couple test directories with the column Blocksize.

Also it might (??) be ignoring according to your gitignore if that is relevant? Or behaving differently wrt symlinks?

Seems like the default behavior should be whatever is most expected, standard and obvious. Or else give user a hint.

I find this in the repo, is t relevant?: bug: Inconsistent Size Display in `exa` Command for Large Files (1024 vs. 1000 Conversion) · Issue #519.

don't forget eza --version. I find it is not updated quickly in every distro. See changelog; it looks like there might have been a relevant update as recently as [0.18.6] - 2024-03-06. Actual my system is only updated to 0.17.3 now that I check this too.

I guess it would be too much to get a set of metronomes eh.

soooo how do I access it?

Not everyone can have 2 computers for all kinds of reasons.

Everyone do you best. Prioritize your data and take stronger precautions for the most important.