Page MenuHome GnuPG

Kleopatra: Allow users to change name of sign/encryption result if (archive) file already exists
Closed, ResolvedPublic

Description

Noticed while working on T5478: Kleopatra: Performance problems decrypting and encrypting large Archives.

Currently, Kleopatra happily starts the sign/encrypt operation if the archive file already exists. When the operation is almost completed, Kleopatra asks whether the existing file should be overwritten or the operation shall be canceled. With no way to save the file with a different name. (But, of course, the user can move the existing file out of the way if they want to keep it.)

This should be improved by checking for an already existing file before starting the operation.

Update: Checking for file name conflicts before starting the operation would defer the start of the operation. And we cannot be sure that no file name conflict occurs when a long running operation is finished. So, instead we offer the users to change the name of the result in case of a file name conflict.

Event Timeline

ikloecker created this task.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Feb 15 2023, 8:18 AM
ikloecker renamed this task from Kleopatra: Check if (archive) file already exists before starting sign/encrypt (archive) operation to Kleopatra: Allow users to change name of sign/encryption result if (archive) file already exists.Feb 22 2023, 11:32 AM
ikloecker updated the task description. (Show Details)
ikloecker changed the task status from Open to Testing.Feb 22 2023, 11:56 AM
ikloecker removed ikloecker as the assignee of this task.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

Ready for testing. In case of a file name conflict the users are now offered to Overwrite the existing file or to Rename the new file (i.e. save it with a different name). If multiple output files are created (e.g. when encrypting multiple files separately), then the users are additionally offered the options "Overwrite All", "Rename All", "Skip", "Skip All".

If the user selected Skip, Skip All, or Cancel, the result is currently displayed the same (i.e. "operation was canceled"). This could be improved, but the output of the result anyway needs an overhaul to make it more user friendly. -> other story

ebo claimed this task.
ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ebo added a subscriber: ebo.

This works, basically.

If you rename to another existing filename, you are not offered the option to overwrite. Instead you are asked to choose a new name. Which works but I would expect a consistent behavior in case of name conflicts throughout the application.

I would vote for a more user friendly behavior for the other options, too. But as you said, other story.