Followup on this is: T6574

I noticed this recently, too. Should be fixed. Especially if we want to use this in KMail, too.

I changed the title accordingly. I think when we call the option "restart background processes" we should not implicitly rely on a non empty keylist to start the gpg-agent but instead trigger it explicitly

I think the priority is low because the optional columns are not really that useful for most users and were mostly added as a "nice to have" feature. The details are in doubt available e.g. through the certificatedetails widget.

This will not translate into the new addon and is too large a change for the current one.

This no longer happens. It was a case of such inline signature images. Maybe if they are added through the clipboard they dont get a filename or something like that.

I do not agree that this will help much, but I am all for changing the string "Find more info on Wikipedia" into something like "See the Quickguide for a short introduction".

I give it the same prio as the parent task

Yes, this should be a fairly low hanging fruit and would improve UX for some users probably quite a bit. So while not very important I give it high priority because we should do it sooner.

I would give this normal priority still. In guess in most cases its not an issue but when it is an issue it will feel like a bug.

Yes this would be a bit more consistent. The idea was that when decrypting there is not much to see in the window so the only actionable item should be at the top. But consistency is better.

! In T6561#172087, @werner wrote:
FWIW, gpg shows the actual cipher and encryption mode with -v. For example

In T6561#172083, @werner wrote:

s/CBC/CFB+MDC/

Strange though, it appears that it is cancelled before finishing the job, no result file is created. But maybe that is when finalize or something would be called in Kleo.

When testing this I noticed that the cancel does not seem to have an effect on normal file jobs run directly through Kleo either: T6560 This is probably not a regression as you fixed here that the cancel is even propagated to the jobs but still I find that disturbing and buggy.

Yes, that was the intention eva reminded me that I had not done this yet, but the next releases of GnuPG VSD will have action/help_contents=false in their action restrictions.

rGb1ecc8353ae3 is just what I meant, so that we can recommend such an option in the future as a workaround until a new update becomes available which supports such an extension.

For support reasons I would say that it might make sense to also ignore the extensions from "ignore-cert-extension" when checking CRLs?

I tested this with OpenPGP and 2.4.3-beta19 on Windows. Worked nicely.

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.

I'm reopening this. Its probably not a regression but I was sure that we had progress for large files fixed in the past.

Yeah no progress for files larger then 32 bit o.O... But this used to work 😭

On 64 bit linux this works btw. so I think it comes down to the difference between 32 bit off_t and 64 bit off_t

Yeah, its the ugly off_t again. I am just testing how this works with single files above that threshold we worked quite a bit on this back in the days https://dev.gnupg.org/T2368

Well staying at 0 is imo worse then knight rider because that looks "stuck" and knight rider looks "working".

So we basically let gpgtar pick the folder name again.

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.

Ok

Probably some issue with large files / integer overflow. I am testing on Windows with 32 bit.

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

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

Mh, let me check where the size hint should come from and why it might be missing in my windows test. That is indeed strange then.

btw. this does not work on the decrypting side because kleopatra there apparently does not provide a size hint. So it goes:

As I already had my testsetup open I recompiled with your change and I tested manually cancelling and letting it run into the disk full error. In both cases the temporary file was deleted and the job was cancelled :)

Oh my, so I have not really tested this for nearly three months and had my head in the send when reviewing it. I really need to apologize for that. The performance improvement is _not_ what I hoped for if it is even there.

Please note that my test was not on an USB Device. I will keep this issue with your analysis and reopen a different one with my error and details on how to reproduce that one. Pretty sure it was disk full.

Just as a background. This issue and others basically ended a project where dan and me worked on with a customer (you know who) to make Kontact from KDE 4 usable for them back in the day. The calendar was just too unreliable and this was one of the causes we identified. This does not mean that it will fix the unreliableness that we see with our calendars at work, but it is an issue that should be fixed.

Yes thinking about this a bit more the checkbox is as redundant as any warning. The user interface clearly indicates that if you want to encrypt for others that you have to enter a name or email in this group. If the user does not notice that then a warning message or other explicit action will not help but make the user experience for most other users (requiring a click to check the checkbox) worse.

Ah, I was not even thinking about the checkbox, yes you are both right. The encrypt to others should not be a checkbox but can be implicit regarding the selection of keys in the group "Encrypt to others."

I don't think a different foldername there would make a difference. When this is not updated it shows wrong information so I have changed this to T6525

We can do an added status line "Note: Only your key will be able to decrypt this file". But I don't think that will be very accessible.