Created attachment 182286 [details] Screen recording showing the compression workflow SUMMARY When using Dolphin to compress a bunch of files, if the "Folder" field points somewhere that does not exist (e.g. /tmp/doesnotexist) or the destination folder does not have write permissions, the operation appears as "completed" even though no archive is produced. This confused me since I accidentally mixed up the folder and filename fields. STEPS TO REPRODUCE 1. In Dolphin, select a bunch of files, right click, "Compress" → "Compress to..." 2. In the "Folder" field, enter a path that does not exist (e.g. "/tmp/doesnotexist") 3. Click OK. OBSERVED RESULT - A notification appears saying it was "Completed". - The "Compress to Archive" dialog closes, need to start again. Dolphin also tries to open the archive destination folder but shows an error: >WorkingDirectory= expects an absolute path or '~' I had this auto-open "feature" patched out (BUG 469762) so I didn't observe this on my main system. EXPECTED RESULT Either: - Show an 'alert' warning within the "Compress to Archive" dialog that the folder is unwritable, or does not exist, or cannot be empty. - Or, check the folder path when pressing "OK", and prompt if I want to create that path, or tell me it's unwritable (e.g. it's read-only) In either case, the "Compress to Archive" dialog stays open, so I can make amendments and try creating the archive again. SOFTWARE/OS VERSIONS Arch Linux KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.1 ADDITIONAL INFORMATION Related: BUG 487237 Worth mentioning is that if there isn't a path in the "Folder" field, it defaults to the home directory. Might be worth warning the user, preventing relative paths, or assume the user meant a subdirectory in the folder where the "Compress to..." action was triggered?
I can reproduce this with Ark built from git master. Thanks! Marking as See Also a similar bug in which a notification is titled "Finished", but the requested action didn't complete as expected.