Byron
Marking parent directory for deletion counts children twice
I marked ~/.cache/yay/packages for deletion, and then decided I could get rid of all of it: selecting ~/.cache/yay/ for deletion results in dua saying it's going to delete 16 GiB, while it's actually only going to delete 9.
Thanks for posting!
It's a known issue, which won't be a show stopper as double-deletion of files has no effect, so Ctrl+R still works as expected.
It's probably something that is easily fixable, too.
@Byron Hello, I'm interested in taking a look at this issue. I stumbled across the project earlier today and I'm liking it so far - it has already been much faster than waiting on standard du! I'm fairly new to Rust, but experienced in several other languages.
I see that the calculation is being made in MarkPane::render with the following line. My first impression is that the iterator could be filtered to exclude any EntryMarks that represent a directory that exists in a subdirectory of another EntryMark.
format.display(marked.iter().map(|(_k, v)| v.size).sum::<u64>())
The naive approach would seem to be another iteration in that filter over all of the EntryMarks and canonicalizing the paths to account for symlinks. My concern with that approach is that it turns an O(N) iteration into an O(N^2) operation in the render loop. If the EntryMarkMap is relatively small, that may not be a major issue.
Would you say I'm on the right track here, or would the better approach be to prevent entries from being marked if they already have a parent directory in the EntryMarkMap? That would move the more expensive calculation outside the render loop, but would raise some additional questions about the desired behavior.
I'll try to get some actual code in place in the morning when I've had a bit more time to look through the existing code and get a better feel for it.
Thanks! Angel Lomeli
Hi @AngelLomeli ,
so great to hear you would like to give it a try, and here you will receive nothing but encouragement in that undertaking :)!
You are right, applying the filter at render time might be doing unnecessary work, and maybe doing it when the entry is added is a better choice. Then even the naive, slow approach might be absolutely good enough.
A good place to get started is to check what happens when a key is pressed - the event loop is where it all happens.
The desired behaviour you are free to experiment with, and for better user experience you might even set a message to be shown in the footer.
Something I recommend you to do is to adjust the existing journey tests which bring up the whole application and inject key presses. That way you can literally trigger the marking and assert the entries in the marking pane.
Lastly, to run tests automatically whenever something changes, you can use make continuous-unit-tests, which employs watchexec under the hood.
That's how I would do it anyway, you will find an approach that works best for you.
Cheers
