Bug 452640

SUMMARY

When archiving some project folders into a `tar.zst` file, the process appeared to have gone smoothly with no errors raised.

The content that was owned by root (Docker volume mounts) was silently skipped without informing me of the omitted or corrupt (empty but non-zero sized) data.


STEPS TO REPRODUCE
1. Have some content with permissions that would prevent read access.
2. Compress that content to an archive via Ark. Note, in Dolphin context menu, "Compress" action will be disabled if lacking write permissions, use a parent directory with write permissions as a workaround.


OBSERVED RESULT

- Via Dolphin "Compress" right-click content menu, UI will appear successful.
- Via opening Ark through a Terminal, the directory contents not readable is filtered out of the archive. No error via GUI or terminal output.
- Via Ark GUI, adding a specific file explicitly instead of the parent directory will add the file of that size but is misleading as there is no actual content (blank).


EXPECTED RESULT

It should be raised as an error when content cannot be archived due to lack of read access permissions.

Especially when adding such a file that is listed in the file picker dialog (with badge indicating lack of read-access), which presently gives the impression it was added successfully but is in fact an empty file but with the expected filename and size.

I did not expect the Ark GUI to implicitly write files that were added via menu immediately to the target archive file either, but that is a separate UX concern.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma:  X11 with Kernel 5.15.28
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3


ADDITIONAL INFORMATION

In comparison, doing a copy operation via Dolphin, the read access failures will create dialogs "Could not read" with Retry/Skip/Skip-All/Cancel options. That's somewhat better but is a UX problem when the number of files that would raise this warning is large:

- Retry is useful if opting to correct permissions, though in some contexts that's not desirable, it'd be better to request auth.
- Skip is useful when the affected paths should be noted down to address afterwards.. but is not pleasant if there's over 100 dialogs like this for very similar paths (usually many having common parents).
- Skip All becomes the preferred action when it's frustrating to respond to an unknown amount of dialogs like this, but at the expense that you lose what those paths were as a result.

A better UX would be to log the path under the same error context and notify the user afterwards, perhaps with some options to handle individual files or in bulk. A tree-view list would be most helpful for context, but a sorted list of paths would work just as well for presenting that information requiring attention.

At the very least, the user should be informed about omitted data or data written with expected filename + size but not the real content.