Note that Kleopatra has code that should take care of removing a left-over file. See also T6530#172608.

It is present in gpg4win 4.2.0. I do not have a later testversion.

Kleopatra should (try to) delete the file: rKLEOPATRA59652a394662: Remove the output file if job was canceled or an error occurred. The attempt to delete the file is logged, so you should see the logs in the debug output. If nothing is logged, then something weird is happening. Or the QFile::exists() check does not work for some reason.

Debugview shows:

[8412] org.kde.pim.kleopatra: Collection Progress:  48  total:  1000
[8412] org.kde.pim.kleopatra: 
[8412] org.kde.pim.kleopatra: 0x9cfca58 slotWizardCanceled
[8412] org.kde.pim.kleopatra: Kleo::Crypto::SignEncryptFilesController(0x64c97a8) cancel
[8412] org.kde.pim.kleopatra: Kleo::Crypto::SignEncryptTask(0xeee73c0) cancel
[8412] org.kde.pim.kleopatra: Error:  "Abbruch durch Benutzer"
[8412] org.kde.pim.kleopatra:

I think the problem is that SignEncryptTask is destroyed before the canceled job reports the result. Therefore the clean-up code never runs. The added logging should confirm this.

it was decided to write the encrypted archive with ending .part and only rename it at the end. In this way the users can't think they have a valid encrypted archive

With VS-Desktop-3.1.90.277-Beta the temporary file ends with .part now and is renamed properly when the job ends successfully.
But it is not removed when the job is aborted.

Does this count as solved?

In T6584#177453, @ikloecker wrote:

We now use a temporary .part files when creating the archive. On success, they are renamed. Otherwise, they are removed (if possible).

I would say no, because the "Otherwise, they are removed (if possible)" is not solved. And if you abort a job it should be possible or we need to make it possible to remove the file.

If you cancel a download the part file is also removed. If the browser crashes, the part file is not removed. That is the behavior I would expect here, too.

Exactly. If possible. Kleopatra tries, but it's not able to remove the file. Because some process in the background keeps it open.

Then we need to kill it with fire! :) Or maybe some context is still open at the time that keeps the process alive? I could investigate on windows. But on linux it might be easier to just breakpoint kleo right before the delete and do an lsof on the file? even though on linux the deletion would likely succeed.

Some observations on Linux:

• If I cancel sign&encrypt archive while the encryption is still running then Kleopatra removes the .part file. I didn't see a running gpgtar or gpg process after I canceled.
• If I cancel sign&encrypt archive by canceling the pinentry (asking for the password of the signing key) then the gpgtar and gpg processes keep running for a short time and Kleopatra still shows the progress. Eventually Kleopatra shows an error (General Error) instead of simply closing the window (-> T6575: gpgtar: General Error is emitted instead of more specific error codes). In this case Kleopatra didn't (have to) remove the .part file because it was already gone.

works, the .part file is deleted on Windows, too, VS-Desktop-3.1.90.287-Beta

(It takes maybe 10 second before the file disappears when you hit F5 in the explorer)

In T6584#179021, @ebo wrote:

(It takes maybe 10 second before the file disappears when you hit F5 in the explorer)

Makes sense because we try to delete the file every 10 seconds:

static const auto timeout = std::chrono::seconds{10};