Enhancement request: refresh/recompute

[FedericoStra]

Hello again,

here is another idea for a potentially useful feature: add the possibility to refresh the entry list and recompute the sizes and percentages. This could be bound to the key r.

This is useful if the files are modified (added, removed, resized) outside of the application while it is running in interactive mode.

[Byron]

That would certainly be nice to have!

Implementing it well is something that wouldn't come easily to me as…

• it should be affecting only the directory tree one is currently displaying
• it should be interactive
• it should handle multiple refresh requests gracefully and properly

Instead of this vision of the perfect implementation of it maybe there is a cheaper way.

What about adding a command-line flag that allows to pass the 'root' directory at which the GUI should start. A refresh request could then exec dua with that flag to relaunch the GUI with the previous roots but display at the given one. While it's coming up refresh is disabled, but besides that it's just as if you would have relaunched the GUI while jumping to the target directory as fast as possible.

What do you think?

[austinbutler]

The way I end up using this tool mostly is dua i /some/path (so it already has the path). It computes the space, then I may end up using an external tool to delete some files. I'm in a descendent of the original path I passed to dua and I want to press r and recompute the current directory recursively and without waiting for everything else to have to recompute. If re-execing dua accomplishes that it seems ok.

[Byron]

The way I end up using this tool mostly is dua i /some/path (so it already has the path). It computes the space, then I may end up using an external tool to delete some files.

I hope you find it useful that it now prints the paths that were selected when exiting.

[LoganDark]

What about adding a command-line flag that allows to pass the 'root' directory at which the GUI should start. A refresh request could then exec dua with that flag to relaunch the GUI with the previous roots but display at the given one. While it's coming up refresh is disabled, but besides that it's just as if you would have relaunched the GUI while jumping to the target directory as fast as possible.

Wouldn't that cause it to forget everything else? (apologies, I am late.)

[Byron]

That's true, in this example it would definitely forget files selected for deletion. In another step one might be able to pass these as well. Doing so would certainly complicate things, so maybe doing the refresh internally would end up being way easier.

[LoganDark]

it would definitely forget files selected for deletion

I was more thinking it'd forget, like, everything (including the files and directories outside the one you're viewing that had already been scanned for their size).

[ww7]

This feature, probably most wanted from 2021

[gosuwachu]

I wonder what is the use case for this feature. I get that if you delete the files outside of dua then that feature would be useful, but dua already supports deleting items from inside the program. So are users not aware that this is possible?

[ww7]

@gosuwachu
In my case I am using dua on remote servers and often need to re-check and preview files/folder with filemanager and mostly delete outside because navigation and overview better in filemanager.

[bcc32]

You might also do other operations than deleting, such as moving, renaming, etc. Also, there may be certain reasons you don't want to delete from dua but instead delete from another application (Adobe Lightroom Classic for example, where you want to keep the state of the photo catalog consistent with the disk files).

[gosuwachu]

I am thinking about implementing it and want to brainstorm few options we have:

1. exec

What @Byron has suggested earlier. Downside is that we lose the state completely, but it should be easy to implement. We could serialise the state as an improvement.

2. big-bang refresh

Create new tree for the current directory and only update it after the scan has completed. The fastest and relatively easy to implement. Downside is you will only see the updates after the scan finishes. UX should be acceptable when refreshing smaller subdirectories, but it is a degraded UX in comparison to the interactive and live scan you get when you launch dua.

3. live refresh

Same as above, but the tree is updated live (maybe after every 200ms like it is today during initial scan). I have started implementing it as it can be used to implement #82, but I am not convinced it is worth the effort anymore as 2. would give us almost the same result with less cost.

4. watch file system changes

Using something like: https://github.com/notify-rs/notify. However inotify API on linux is tricky to get right, so this is probably most difficult, but probably has the best UX.

What other similar tools do?

ncdu,gdu, Gnome Baobab & DaisyDisk all implement option 2. + they block the UI while the refresh is in progress.

[Byron]

Thanks a lot for the analysis!

After having been reminded of the beauty of crossbeam::select() I think it should be possible to refactor the way the GUI is built to allow updates at any time. It should be as simple as accepting crossbeam channels directly for events and another one for 'create-or-update-entry' data. Thus, building the tree wouldn't be any different from updating it.

An entirely 'new' mechanism would be needed to signal that a refresh is supposed to take place, for that the event loop would have to be able to signal the holder of the send-end of the 'ccreate-or-update-entry' channel to start sending new data for a particular root node. This signal could probably be another channel.

In order to get there, I'd first refactor the way the initialization is done to the new design as described above, which should be the same for the user in terms of performance and responsiveness. As second step, i'd add the 'signalling' channel to communicate which node should be updated, which will cause new nodes to stream in.

Of course, the devil will hide in the details here 😅, but I think that's the cleanest solution which will stay true to the UX we have right now, which, TBH, I wouldn't want to compromise on.

With the architecture above, another great feature would be enabled BTW: live-visualization of which directory it's currently traversing into. What's more obvious now that it's super-responsive during scanning is that it looks like certain folders aren't there at all even though they just aren't there yet. Hence, it would be great if these 'in-progress' folders would be displayed . From there, it would even be possible to display the amount of children it traversed thus far as some kind of 'progress' until it finally 'pops in' so the user can enter it. A side-effect of this would be there would always be multiple in-progress entries as it's multiple threads doing the work, so probably very cool to look at indeed :D.

[gosuwachu]

I like it. What makes it even better is that dua would have superior UX in comparison with the other tools 😎

[gosuwachu]

fyi, I do have a work-in-progress version of refactored app startup based on crossbeam, but I need to go through few clean-up iterations 🎉

[Byron]

This feature has been implemented with this release.