If it’s a crash, please include the full text of the crash that gets printed to the screen. If you’re seeing unexpected behaviour, a screenshot of the issue will help a lot.
Today I noticed a discrepancy in the output of total folder sizes, compared to other programs. eza had way too high numbers for some folders. As comparison I looked at the filemanager Dolphin (properties with right mouse click) and with commandline tool:
du --human-readable --apparent-size --all --max-depth 1 ./trampoline
with and without --si option. The 1000 vs 1024 base of bit counting is not the issue here. After some digging into my files and folders and comparing stuff, I found out that for hardlink files eza counts them individually. But that is wrong, because those files exist only once on the drive and require the space only once. ls can show the number of hardlinks each file has:
System Information
eza --version
)If it’s a crash, please include the full text of the crash that gets printed to the screen. If you’re seeing unexpected behaviour, a screenshot of the issue will help a lot.
The problem
Today I noticed a discrepancy in the output of total folder sizes, compared to other programs.
eza
had way too high numbers for some folders. As comparison I looked at the filemanager Dolphin (properties with right mouse click) and with commandline tool:with and without
--si
option. The 1000 vs 1024 base of bit counting is not the issue here. After some digging into my files and folders and comparing stuff, I found out that for hardlink fileseza
counts them individually. But that is wrong, because those files exist only once on the drive and require the space only once.ls
can show the number of hardlinks each file has:The
2
is the number of hardlinks for the same file.