16 stable releases
✓ Uses Rust 2018 edition
|new 2.1.8||Jul 14, 2019|
|2.1.7||Jul 3, 2019|
|2.1.3||Jun 16, 2019|
|1.2.2||Jun 5, 2019|
429 downloads per month
dua (-> Disk Usage Analyzer) is a tool to conveniently learn about the usage of disk space of a given directory. It's parallel by default and will max out your SSD, providing relevant information as fast as possible.
cargo, which can be obtained using rustup
cargo install dua-cli
xbps on your VoidLinux system.
# count the space used in the current working directory dua # count the space used in all directories that are not hidden dua * # learn about additional functionality dua aggregate --help
Launch into interactive mode with the
interactive subcommand. Get help on keyboard
Use this mode to explore, and/or to delete files and directories to release disk space.
Please note that great care has been taken to prevent accidential deletions due to a multi-stage process, which makes this mode viable for exploration.
dua i dua interactive
- Evaluate unit coloring - can we highlight different units better, make them stick out?
That way, pressing
shift + O to open the currently selected file won't possibly spam the terminal
with messages caused by the program used to find the system program to open the file.
- Performance fix when showing folders with large amounts of files
- Display of amount of entries per directory
- Better information about deletion progress
- removal of windows support
- windows support (never actually worked), usage of crossterm is difficult thanks to completely different input handling.
- additional key-bindings
- auto-restore previous selection in each visited directory
- fix typo in title
- better display of IO-Errors in aggregate mode
A sub-command bringing up a terminal user interface to allow drilling into directories, and clearing them out, all using the keyboard exclusively.
- Single Unit Mode, see reddit
That's that. We also use
tui-react, something that makes it much more pleasant to handle the
application and GUI state.
Simple CLI to list top-level directories similar to sn-sort, but faster and more tailored to getting an idea of where most space is used.
Thanks to jwalk, all there was left to do is to write a command-line interface. As
jwalk matures, dua should benefit instantly.
- Interactive mode only looks good in dark terminals (see this issue)
- Hard links are not understood, thus hard-linked files will possibly be counted multiple times.
- Symlinks are followed and we obtain the logical size of the file they point to. Ideally, we only count their actual size.
- logical filesize is used instead of computed or estimating actual size on disk.
- easy fix: file names in main window are not truncated if too large. They are cut off on the right.
- There are plenty of examples in
tests/fixtureswhich don't render correctly in interactive mode. This can be due to graphemes not interpreted correctly. With Chinese characters for instance, column sizes are not correctly computed, leading to certain columns not being shown. In other cases, the terminal gets things wrong - I use alacritty, and with certain characaters it performs worse than, say iTerm3. See https://github.com/minimaxir/big-list-of-naughty-strings/blob/master/blns.txt for the source.
- One cannot abort the filesystem traversal
- as we are in raw terminal mode, signals will not be sent to us. As as we are single-threaded in the GUI, we can not listen to input events while traversing the filesystem. This can be solved, of course, and I would love the solution to use async :).
- In interactive mode, you will need about 60MB of memory for 1 million entries in the graph.
- In interactive mode, the maximum amount of files is limited to 2^32 - 1 (
u32::max_value() - 1) entries.
- One node is used as to 'virtual' root
- The actual amount of nodes stored might be lower, as there might be more edges than nodes, which are also limited by a
- The limitation is imposed by the underlying
petgraphcrate, which declares it as
unsafeto use u64 for instance.
- It's possibly UB when that limit is reached, however, it was never observed either.
- Dedication to
- we use
termionexlusively, and even though
tuisupports multiple backends, we only support its termion backend. Reason:
tuiis only used for parts of the program, and in all other parts
termionis used for coloring the output. Thus we wouldn't support changing to a different backend anyway unless everything is done with TUI, which is really not what it is made for.
- we use