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.

Installation

Via cargo, which can be obtained using rustup

cargo install dua-cli

Usage

# 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

Roadmap

🚧v2.0 (wip) - interactive visualization of directory sizes with an option to queue their deletion

A sub-command bringing up a terminal user interface to allow drilling into directories, and clearing them out, all just using the keyboard.

Other Features

• Single Unit Mode, see reddit
• Evaluate unit coloring - can we highlight different units better, make them stick out?

✅v1.2 (released) - - the first usable, read-only interactive terminal user interface

That's that. We also use tui-react, something that makes it much more pleasant to handle the application and GUI state.

✅v1.0 (released) - aggregate directories, fast

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.

Development

Run tests

make journey-tests

Learn about other targets

make

Acknowledgements

Thanks to jwalk, all there was left to do is to write a command-line interface. As jwalk matures, dua should benefit instantly.

Limitations

• 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 u32 (I guess)
  • The limitation is imposed by the underlying petgraph crate, which declares it as unsafe to use u64 for instance.
  • It's possibly UB when that limit is reached, however, it was never observed either.
• Dedication to termion
  • we use termion exlusively, and even though tui supports multiple backends, we only support its termion backend. Reason: tui is only used for parts of the program, and in all other parts termion is 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.