Backported for VSD 3.4

I think this is a very good idea. Go ahead an backport, I'll change the ticket description accordingly.

I'll wait for feedback before I backport this.

Instead of adding yet another option I have optimized the case that a single archive containing a single top-level folder is decrypted/extracted (which, typically, is the result of encrypting a folder). In this case, the single top-level folder extracted from the archive is moved to the user-given output folder instead of the outer temporary folder the archive was extracted to. I think that's what most users anyway expect so that an option is superfluous. In case the extracted folder clashes with an existing folder in the user-given output folder then, as usual, the moved folder gets a numbered suffix to avoid the naming collision.

this was resolved

There is another customer request for this too.

Gpg4win 4.4.0 has just been released. Creation of encrypted archives has been completely reworked with Gpg4win 4.3.0 already. I could create an encrypted archive containing the two files with GpgEX without problems.

tested with Gpg4win-Beta-75++

This is included in test installers since some time already.

This change is also used for VSD 3.3

Fixed for all branches.

If 7z is used to create a tarball that tarball is then 7z compressed. At least this is how I understand the case.
When gpgtar now tries to extract the file it sees a 7z file and thus emits the octal number warnings because it assumes a tarball (after decryption by gpg).

This problem was also reported at https://bugs.kde.org/show_bug.cgi?id=479567#c1

While reviewing this task I noticed that I wrote adding a -p option. This is non-sense, because -p is to preserve permissions at extract time; this is unrelated to the last modification time. Standard tar extract files and set the modification to the one given in the tarball - unless you use -m to use the current time. Thus this task is actually a bug and not a feature request. For backward compatibility this will be done only for gnupg26 for now.

This ticket is obsolete, we did some work on gpgtar since then. Should the issue still occur, please reopen or create a new ticket

We won't do that for Windows.

gpgme now checks for a SUCCESS status emitted by gpgtar when creating a signed and/or encrypted archive. If gpgtar is killed (or exits without emitting SUCCESS for some other reason) then the partially created archive is removed and Kleopatra reports a failure.

Status messages on successful creation of signed & encrypted archive

2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar c 0 3<LF>
2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar s 0 62 B<LF>

Because a user in https://mstdn.social/deck/@GnuPG/113011825339406300 did read the documentation, I had a look in the documentation and in other public definitions (e.g. https://www.gnu.org/software/tar/manual/html_node/Formats.html#Formats) and I can understand the questions of the user.

gpgtar is compatible to PGP Desktop's format which they call ZIP. This is technically ustar with the most common extensions. Don't let us go into yet another TAR format discussion.

Nobody uses gpgtar for S/MIME

What happens if you call gpgtar with --utf8-strings --cms additionally to the other options? And what happens if you pipe the archive to gpgtar's stdin?

The original issue was to unclear to analyse and it was likely meanwhile fixed. For the other issue see the follow up ticket.

I mean this would also be solved if we did not use qiodevicedataprovider but pass the filenames directly to gpg for single files, too. (can't remember the ticket number) but I don't want to do that right now.

In T6526#177082, @ikloecker wrote:

The original issue was about creating an encrypted archive. This code doesn't use Qt anymore for writing the result file, but delegates this to gpgtar.

That sounds like a solid conclusion. I mean if errno is not set explicitly it is basically undefined which value it is, so maybe some other function set errno to no space left on device in that one case where it "worked".

The original issue was about creating an encrypted archive. This code doesn't use Qt anymore for writing the result file, but delegates this to gpgtar.

I've debugged Eva's problem and I think it's unrelated to the original problem, as it's specific to qt.

As what I see is similar as what Andre saw, I'll describe it here. Please check if this is relevant.
After the above mentioned Ticket was resolved, I tried the exact same encryption in Kleopatra on the same Test-VM.

That should be easy on Unix but on Windows we have the nul nul: and iirc also /dev/nul.

In T6556#175399, @werner wrote:

@iklocker: Which gpg bug to you mean?

@iklocker: Which gpg bug to you mean?

Thanks. For the record, done at https://lists.gnupg.org/pipermail/gnupg-users/2023-August/066692.html.