https://bugs.kde.org/show_bug.cgi?id=452640
Bug ID: 452640
Summary: Ark does not notify on failure to archive content due
to insufficient read permissions
Product: ark
Version: 21.12.3
Platform: Manjaro
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: elvis.angelac...@kde.org
Reporter: polarathene-sig...@hotmail.com
CC: aa...@kde.org, rthoms...@gmail.com
Target Milestone: ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
