* common/dotlock.c (any8bitchar) [W32]: New.
(dotlock_create_w32): Use strconcat and CreateFileW.
* common/t-dotlock.c: Source include dotlock.c and modify to allow
manual testing on Windows.
--
GnuPG-bug-id: 5098
Signed-off-by: Werner Koch <wk@gnupg.org>
(cherry picked from commit b47c355b18d9537ccc3dd3e80cc1825b018ecff7)
* common/libjnlib-config.h: Remove.
* common/common-defs.h (getenv) [HAVE_GETENV]: New. From removed
header.
(getpid) [HAVE_W32CE_SYSTEM]: New. From removed header.
* common/argparse.c: Include util.h and common-defs.h. Replace
jnlib_ macro names for non-GNUPG builds by x* names.
* common/dotlock.c: Ditto.
* common/logging.c: Include util.h and common-defs.h. Replace jnlib_
symbol names by x* names.
* common/strlist.c: Ditto.
* common/utf8conv.c: Ditto.
* common/w32-reg.c: Ditto.
* common/mischelp.c: Ditto. Also remove _jnlib_free.
* common/stringhelp.c: Ditto.
(JNLIB_LOG_WITH_PREFIX): Do not depend on this macro.
* common/logging.h (JNLIB_LOG_WITH_PREFIX): Do not depend on this
macro.
--
This is part 1 of the patches to merge the jnlib files into common/.
It does not make much sense to keep jnlib/ files separate. They are
not often use elsewhere and maintaining the complex marcos stuff is
too troublesome for the future.
Signed-off-by: Werner Koch <wk@gnupg.org>
* common/dotlock.c: (dotlock_create_unix) avoid double-close()
in unusual situations.
--
close(2) says:
close() should not be retried after an EINTR since this may
cause a reused descriptor from another thread to be closed.
Before this patch was applied, if close(fd) failed with EINTR, it
would be closed again in the write_failed: block.
It could also have been closed a second time in the case that
(use_hardlinks_p (h->tname)) evaluated to something other than 0 or 1.
This patch avoids both of those scenarios.
Note that close() could still be called twice on the same file
descriptor if the first close(fd) fails but errno is not EINTR. I'm
not sure the right thing to do in that scenario. An alternate
resolution could be to unequivocally set fd to -1 after the first
failed close(fd), avoiding the errno == EINTR test.
Debian-Bug-Id: 773423
* agent/call-scd.c (start_scd): Replace int by assuan_fd_t.
(start_pinentry): Ditto.
* common/asshelp.c (start_new_gpg_agent): Replace int by assuan_fd_t.
* common/dotlock.c (GNUPG_MAJOR_VERSION): Include stringhelp.h for
prototypes on Windows and some other platforms.
* common/logging.c (fun_writer): Declare addrbuf only if needed.
* g10/decrypt.c (decrypt_message_fd) [W32]: Return not_implemented.
* g10/encrypt.c (encrypt_crypt) [W32]: Return error if used in server
mode.
* g10/dearmor.c (dearmor_file, enarmor_file): Replace GNUPG_INVALID_FD
by -1 as temporary hack for Windows.
* g10/export.c (do_export): Ditto.
* g10/revoke.c (gen_desig_revoke, gen_revoke): Ditto.
* g10/sign.c (sign_file, clearsign_file, sign_symencrypt_file): Ditto.
* g10/server.c (cmd_verify, gpg_server) [W32]: Return an error.
--
The gpg server mode is not actual working and thus we can avoid the
warnings by explicitly disabling the mode. We keep it working under
Unix, though.
The asymmetric quotes used by GNU in the past (`...') don't render
nicely on modern systems. We now use two \x27 characters ('...').
The proper solution would be to use the correct Unicode symmetric
quotes here. However this has the disadvantage that the system
requires Unicode support. We don't want that today. If Unicode is
available a generated po file can be used to output proper quotes. A
simple sed script like the one used for en@quote is sufficient to
change them.
The changes have been done by applying
sed -i "s/\`\([^'\`]*\)'/'\1'/g"
to most files and fixing obvious problems by hand. The msgid strings in
the po files were fixed with a similar command.
* common/dotlock.c (use_hardlinks_p, dotlock_take_unix): Check return
value of link().
* g13/g13.c: Make sure err is initialized.
* scd/scdaemon.c (main) [!USE_GCRY_THREAD_CBS]: Do not define ERR.
- It is now more portable and may be used outside of GnuPG
- vfat file systems are now supported.
- The use of link(2) is more robust.
- Wrote extensive documentation.
We better do this once and for all instead of cluttering all future
commits with diffs of trailing white spaces. In the majority of cases
blank or single lines are affected and thus this change won't disturb
a git blame too much. For future commits the pre-commit scripts
checks that this won't happen again.
