search

Byron / dua-cli

View disk space usage and delete unwanted data, fast.
https://lib.rs/crates/dua-cli
MIT License
4.17k stars 113 forks source link

Directories themselves do not contribute to size like they do in `du` #262

Open polarathene opened 2 months ago

polarathene commented 2 months ago

While experimenting with different distro images in Docker, I noticed that du and dua were a bit inconsistent (and later that du itself was inconsistent too with --apparent-size if the version of du was older).

I discovered that dua reported /usr/share/man as only 20KiB, but du was showing about 1MB. This location had many directories nested and most empty. Other locations were like this as well (I had been using zypper --installroot /rootfs install glibc for example to see how much space the package would weigh), contributing several MB in weight invisible to dua for this small glibc package (2.7MB of 10.7MB total). This is due to each directory using a minimum 4096 bytes as the smallest block-size, with a new enough version of du the --apparent-size option will treat these as 0 bytes.

dua has the -A / --apparent-size flag too, but without it directory size seems to still be treated as 0 bytes. Perhaps that is useful for some users vs using dua -A? 🤷‍♂️

The linked discussion comment above suggested to raise an issue about this behaviour since it's technically a bug.

https://github.com/Byron/dua-cli/discussions/121#discussioncomment-10541462

It would probably be more correct if dua would also count empty directories as consumer of an inode, which typically clocks in at 4KiB.

It would be neat if dua interactive also supported toggling between --apparent-size btw, which as a bonus would make it available in the TUI help view?

Byron commented 2 months ago

Thanks a lot for reporting!

I think this issue should remain focussed on making the size-on-disk include directories as consumer of a single block. Supporting the --apparent-size flag for interactive sessions (either interactively or using the flag) should be a separate issue, otherwise it might get lost here.