gpg doesn't fail on target file existing when decrypting
icrf.ml at gmail.com
Mon Mar 16 22:48:18 CET 2009
On Mon, Mar 16, 2009 at 5:17 PM, Doug Barton <dougb at dougbarton.us> wrote:
> Andrew Flerchinger wrote:
> > Yes, I do see that behavior. The primary difference is that I never want
> > it to prompt me for anything, since I'm writing a headless wrapper.
> What you're suggesting isn't "safe" in any case. What I would do in
> your situation is the following:
> 1. Use mktemp to safely create a new, unique file
> 2. Send the decryption output to that file
> 3. Test if the "real" file exists, and if so unlink it
> 4. mv $newfile $realfilename
You're right, I could do that to make my work-around act atomic. Or
are you saying that even the functional encrypt behavior isn't "safe?"
I'm assuming that's essentially what gpg is already doing.
I guess I'm still trying to determine the reason for the inconsistent
behavior between encryption and decryption functions. If it's a bug,
I'd like to report it. If it's a design decision, I'd like to know the
rationale behind why. If it's something else, I'd love to be
More information about the Gnupg-users