Page MenuHome GnuPG

Directory used for decrypted file
Closed, ResolvedPublic

Description

I frequently exchange huge (approx. 35gb) gpg encrypted files (password encrypted) with my partners as part of development projects. Typically these data pakages contain proprietary binary files such as e.g CAD models, documents, etc.), which is the reason, why these files are substentially big. Due to their shear size, the encrypted files are stored on a NAS system accessed via smb-protocol, which has two immediate consequences:

(1.) issuing "gpg -o <Decrypted_file.tar.gz> -d <Encrypted_file.tar.gz.gpg>" in a Win 7 terminal is impracticably slow; decrypting a file with 35gb takes about 12h (or more)

(2.) Decrypting the file via Kleopatra speeds the process up significantly, but the decrypted file is temporarily generated in %temp%, i.e. the temporary directory of the respective user. Thereafter the decrpyted file is by default copied to the folder in which the encrypted file is stored. This is fine as long as the system disk is sufficiently large to generate the decrypted file. But as M.2 SSDs are now becoming increasingly popular (e.g. my laptop), the space may be limited such, as that this operation fails as the %temp% directory runs out of space. My laptop, for instance, features a 256gb M.2 system disk and my CAD and FEA S/W allready consume a considerable part of the disk's capacity. As this is a CAE certified workstation notebook, replacing the SSD with a bigger one (for a furtune btw) just for the sole purpose of decrypting large files isn't an attactive option.

Hence my feature request: Issue (2.) could be resolved easily by providing an option in Kleopetra which allows to generate the decrypted file in the same directory as the encrypted file (and not in %temp%). This corresponds to option (1.), but unfortunately gpg issued on a terminal is far too slow to be used on cifs shares...

Keep up the good work!

Cheers,
Stefan

Event Timeline

steosch created this object in space S1 Public.
aheinecke triaged this task as Normal priority.Dec 11 2017, 11:56 AM
aheinecke added a project: Bug Report.
aheinecke added a subscriber: aheinecke.

I thought about (2) when implementing the new "decrypt" action in Kleopatra but we did not give it high priority as we were unsure if this is a real world problem.

But for the performance problem: I think when Kleopatra is used to decrypt the file directly on the Network share it will become as slow as using gpg on the command line.

The performance improvement you see when using Kleopatra is likely because the decrypted data is written to a local file and not the network drive.

I think the problem here is that GnuPG uses too little chunk sizes when writing data. So it's too many small read / write operations that have to go over the network. Kleopatra can maybe speed this up by using an internal buffer before writing the decrypted output to a file.

I'll open two seperate tasks for this.

aheinecke claimed this task.

I'm changing this issue to resolved as I opened T3601 and T3602 for the problems mentioned in this issue. As it is better to have them separated.