1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
**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.
[![asciicast](https://asciinema.org/a/au3neIHDGtYYj4blyTXR8VkJz.svg)](https://asciinema.org/a/au3neIHDGtYYj4blyTXR8VkJz)
### Installation
Via `cargo`, which can be obtained using [rustup][rustup]
```
cargo install dua-cli
```
### Usage
```bash
# 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
* [x] Single Unit Mode, see [reddit](https://www.reddit.com/r/rust/comments/bvjtan/introducing_dua_a_parallel_du_for_humans/epsroxg/)
* [ ] 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
```bash
make tests
```
#### Learn about other targets
```
make
```
### Acknowledgements
Thanks to [jwalk][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`][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`][termion] exlusively, and even though [`tui`][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.
[petgraph]: https://crates.io/crates/petgraph
[rustup]: https://rustup.rs/
[jwalk]: https://crates.io/crates/jwalk
[termion]: https://crates.io/crates/termion
[tui]: https://github.com/fdehau/tui-rs
|