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.

Works good enough for me

I agree, but can't give this priority because it is more work then it sounds since we need to start from the bottom with dirmngr feedback and then pass this all the way through our layers to kleo.

As ingo pointed out in the main issue, just using an "inactive" color for the validity might be confusing / inacessible.

So the reason this fails is the same as it was back when T3547 was fixed. MoveFile does not work across directories, and even MoveFileEx that supports this for files does not support this for directories.

Can you try on the command line, errors might be more specific there. This can be caused for example by a wrong system clock.

This is not really what the issue here is talking about. This issue was about "merging" multiple keyrings into a single view. If I understand you correctly you want to have matching pubrings and secret key directories for different applications. That is fully covered and what many users do by setting GNUPGHOME through the environment, the --homedir option or the windows registry.

Moved this on the workboard to have a better overview.

Fixed with: 8e258f77114ce0474a2bb6aa1314385e2fb68e15

With the recent commit the old workaround works reliably again.

Mmh, why did this go into its own rc file. I guess its because its in libkleo and not in Kleo itself. I have to check how this works with my registry code. I doubt that this will work out of the box but its important for us that our settings can be set through the windows registry.

I think that you both misunderstand my idea a bit. I would like to present it to you at some point over a Video Call or I have to write the proposal out in some longer form.