Incorrectly resolves symlinks about dua-cli

[Byron]

Right now there is no special handling of symbolic links, and counting them at all as the files they point to is something I would want to avoid in future. Right now DUA relies on the file metadata provided by the metadata() call of the Rust std, which follows symbolic links.

[vks]

I think this is very dangerous, because recursive deleting may follow the links, possibly deleting the whole home folder.

Indeed, traversal follows symlinks. Additionally, symlinks are not currently displayed as such and appear like real files. The latter can certainly be fixed during display, as a first step towards making it more clear what's going on. Not following symlinks at all would require a change in the jwalk create I believe.

However, when deleting files and directories, dua will not follow symbolic links and behave as one would expect. This fix was introduced in v2.1.9.

[vks]

Not following symlinks at all would require a change in the jwalk create I believe.

That is true, but I think it only applies to the non-interactive mode of dua.

However, when deleting files and directories, dua will not follow symbolic links and behave as one would expect. This fix was introduced in v2.1.9.

I think the fix was not correct, see #27.

[vks]

Also see Byron/jwalk#7.

[vks]

This issue should be fixed now for the interactive mode, for the aggregate mode this needs to be fixed in jwalk first.

[Byron]

As symbolic links are not followed, this issue should.

There is still a special case which is dua or dua *, which is when it ignores top-level symbolic links entirely. That can be confusing, as one would still expect them to show up like any other symbolic link. If this is an issue, a new one could be opened for that alone.

Thank you