Page MenuHome GnuPG

gpgtar: Removes existing output file on error
Open, NormalPublic


gpgtar erroneously removes an existing output file if an error occurs.


# create an existing output file and a folder to archive:
$ touch do-not-remove-me
$ mkdir foo

# run gpgtar; enter a passphrase when asked for it; deny overwriting the existing file; press Return when asked for new filename:
$ gpgtar --encrypt --symmetric --output do-not-remove-me foo
File 'do-not-remove-me' exists. Overwrite? (y/N) 
Enter new filename: 
gpg: symmetric encryption of '[stdin]' failed: File exists
gpgtar: running /opt/gnupg/master/bin/gpg failed (exitcode=2): General error
gpgtar: creating tarball 'do-not-remove-me' failed: General error

# observe that your precious existing file is gone:
$ ls do-not-remove-me
ls: cannot access 'do-not-remove-me': No such file or directory

Revisions and Commits

Event Timeline

werner added projects: gnupg24, gnupg22.

This looks like the same problem I encountered in Gentoo's Portage. To unlock the binary package signing key, Portage will run the equivalent of gpg --homedir ... --digest-algo ... --local-user ... --output /dev/null /dev/null. If unlocking fails (due to e.g. wrong password), /dev/null is removed:

It is not yet clear to me if it is the intended behaviour of GnuPG to remove the --output file on failure (in which case the Portage code would simply need adjusting to use some temporary file instead of /dev/null). Or if this is actually a bug in GnuPG that needs fixing.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

Ingo's case is different and related to the fact that though it passes --yes, --no, and --batch to gpg it does not have its own code to to ask for overwriting. That is not consistent. Either we use the standard tar interface (which is to always overwrite) or we use the gpg (PGP2 based) behaviour to ask the user.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

Thanks for clarifying!

It may be better to open a separate issue for the issue in gpg, so that it's not overlooked/forgotten when the issue in gpgtar is fixed.

I would simply redirect output via >/dev/null to avoid the problem. Or, if you want to avoid running the command with shell-mode in Python, then read the output in Python but just don't use it. The command doesn't produce large amounts of output.

Alternatively, send an email to gnupg-users mailing list to ask for a better solution to "unlock the binary package signing key". There may be a more elegant solution than your "sign /dev/null" hack.

@iklocker: Which gpg bug to you mean?

For the gpgtar bug we need to decide whether we want to always overwrite or somehow implement an ask the user. Given that gpgtar has no user interaction I tend to go with the first option. Opinions?

@iklocker: Which gpg bug to you mean?

The issue mentioned in T6556#174630 (i.e. removal of /dev/null) which turned out not to be an issue resp. to be intentional.

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