also sprach Werner Koch <[EMAIL PROTECTED]> [2006.08.17.0814 +0100]: > sed -e edit_stuff < pubring.gpg > pubring.gpg.tmp \ > && mv pubring.gpg pubring.gpg~ \ > && mv pubring.gpg.tmp pubring.gpg
I've just run against the problem again, and it's definitely related
to a SIGINT. If I look at your pseudo-code, and from a cursory look
at thr gpg source code, I think it's not entirely accurate, but
rather seems to be
sed -e edit_stuff < pubring.gpg > pubring.gpg.tmp \
&& mv pubring.gpg pubring.gpg~ \
&& touch pubring.gpg \
&& mv pubring.gpg.tmp pubring.gpg
That is, I can see in the strace that pubring.gpg is read and stuff
is written to pubring.gpg.tmp, and that the former is then backed
up:
6899 rename("/home/madduck/.gnupg/pubring.gpg",
"/home/madduck/.gnupg/pubring.gpg~") = 0
but right after this call, a zero-sized pubring.gpg is left on disk,
which I can't quite explain, because immediately after the rename()
call, the interrupt happens:
6899 --- SIGINT (Interrupt) @ 0 (0) ---
The result is that the .tmp file is left in place and not moved over
the zero-sized keyring file.
I realise that I am misbehaving by interrupting GPG, but I believe
that GPG may not be trapping signals properly if it leaves the
keyring in an inconsistent state (zero-sized pubring.gpg but
non-zero secring.pgp, which is unusable without the pubkey in the
pubring).
Looking at g10/signal.c:got_fatal_signal, I cannot find any
provisions taken to ensure that the temporary files are cleaned up.
Is this by design? Or would you consider adding code that would
ensure that either of pubring.gpg~ or pubring.gpg.tmp (if completed)
gets moved back to pubring.gpg in case of an interrupt?
--
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
signature.asc
Description: Digital signature (GPG/PGP)
