Page MenuHome GnuPG

Gpgtar behavioral change when extracting archives
Open, NormalPublic

Description

Before the gpgtar change we would always save the decrypted files from gpgtar in a subfolder based on the filename of the archive.

E.g. you encrypt test1.bmp and test2.bmp and store them in Archive.tar.gpg

When you decrypted Archive.tar.gpg it would create a folder "archive" and then place test1.bmp and test2.bmp in there.

When you now decrypt Archive.tar.gpg it will ask you to overwrite test1.bmp or overwrite all. No option to rename. As I think the old way was safer and users are used to this I would like to have the old behavior of always decrypting to a new subfolder restored. Users are by now used to this and while I can see that the new way might also have advantages for some workflows I would not like to change this with at least an option to revert to the old behavior.

@ebo this is what you meant by your issue, right?

Event Timeline

aheinecke created this task.

Left is the old behavior after "save all" right is the new behavior after "save all"

No. I only noticed a difference of the behavior between gpgtar on the cli and Kleo. Ingo said the behavior in Kleo has always been the same, gpgtar an Kleo differ in that. Case was therefore closed for me.

Deleted the part with Archive_1_, as I do not see that any more. Must have been only in beta339.

ingo may have tested on linux where we never actually used gpgtar.

I wasn't aware of this behavior (on Windows), i.e. the behavior change wasn't intended.

Regarding

When you now decrypt Archive.tar.gpg it will ask you to overwrite test1.bmp or overwrite all. No option to rename.

That's one reason why we switched to KIO::move which gives the user loads of different options including rename. Until KIO::move is fixed on Windows the users will have to live with the old behavior.

Yes. I think for now we should ifdef the directory change to Linux, must be done in GPGME I think. I know its ugly to have it differently on both plattforms but while extracting in a subfolder might be more uncomfortable our users are used to this and this resolves the issue until we have better options with KIO.

So we basically let gpgtar pick the folder name again.

Which only works if gpgtar actually knows the input file name (which it will once T6530: GPGME / QGpgME Extend Archivejobs to accept input / output from a filename is done and used).

In the past this was done by --set-filename in libkleopatrarc-win32.desktop. But I am happy if we close this and focus on T6530.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ikloecker changed the task status from Open to Testing.Jun 23 2023, 3:55 PM
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.
ikloecker added a subscriber: ikloecker.

Should be fixed.

A minor change is that in case of a conflict while decrypting multiple archives with the same base name, Kleopatra (using KFileUtils) choses unique folder names which are build by appending " (nnn)" instead of "_nnn". In combination with the code that avoids conflicts when moving the decrypted archives from the temporary folder to the final location this may result in folders named "archive (2)_3". But that's the price one has to pay if one names all archives "archive.tar.gpg".

ebo claimed this task.
ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

works. So gpgtar obviously knows about the filenames now, too

aheinecke raised the priority of this task from High to Unbreak Now!.

For S/MIME archives the output for e.g. testfolder.tar.gz.p7m is now named "testfolder.tar.gz_1_/testfolder" with the "_1_" even added if there is no "archive.tar.gz"

Should be easy to fix but I must fix this before the release.

aheinecke moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 12 2023, 4:05 PM

Strangely enough this does not happen on linux. Maybe related to the KMime changes we have there?

aheinecke lowered the priority of this task from Unbreak Now! to Normal.Jul 12 2023, 5:12 PM

Normal priority to get the _1_ removed when no folder with the same name already exists in that location.