2016-01-14 19:51:59 +03:00
|
|
|
#ifdef __MINGW64_VERSION_MAJOR
|
|
|
|
#include <stdint.h>
|
|
|
|
#include <wchar.h>
|
|
|
|
typedef _sigset_t sigset_t;
|
|
|
|
#endif
|
2007-12-01 23:24:59 +03:00
|
|
|
#include <winsock2.h>
|
2009-11-24 01:55:50 +03:00
|
|
|
#include <ws2tcpip.h>
|
2007-12-01 23:24:59 +03:00
|
|
|
|
2016-01-14 19:51:59 +03:00
|
|
|
/* MinGW-w64 reports to have flockfile, but it does not actually have it. */
|
|
|
|
#ifdef __MINGW64_VERSION_MAJOR
|
|
|
|
#undef _POSIX_THREAD_SAFE_FUNCTIONS
|
|
|
|
#endif
|
|
|
|
|
2013-09-08 16:23:27 +04:00
|
|
|
extern int core_fscache;
|
|
|
|
|
mingw: support long paths
Windows paths are typically limited to MAX_PATH = 260 characters, even
though the underlying NTFS file system supports paths up to 32,767 chars.
This limitation is also evident in Windows Explorer, cmd.exe and many
other applications (including IDEs).
Particularly annoying is that most Windows APIs return bogus error codes
if a relative path only barely exceeds MAX_PATH in conjunction with the
current directory, e.g. ERROR_PATH_NOT_FOUND / ENOENT instead of the
infinitely more helpful ERROR_FILENAME_EXCED_RANGE / ENAMETOOLONG.
Many Windows wide char APIs support longer than MAX_PATH paths through the
file namespace prefix ('\\?\' or '\\?\UNC\') followed by an absolute path.
Notable exceptions include functions dealing with executables and the
current directory (CreateProcess, LoadLibrary, Get/SetCurrentDirectory) as
well as the entire shell API (ShellExecute, SHGetSpecialFolderPath...).
Introduce a handle_long_path function to check the length of a specified
path properly (and fail with ENAMETOOLONG), and to optionally expand long
paths using the '\\?\' file namespace prefix. Short paths will not be
modified, so we don't need to worry about device names (NUL, CON, AUX).
Contrary to MSDN docs, the GetFullPathNameW function doesn't seem to be
limited to MAX_PATH (at least not on Win7), so we can use it to do the
heavy lifting of the conversion (translate '/' to '\', eliminate '.' and
'..', and make an absolute path).
Add long path error checking to xutftowcs_path for APIs with hard MAX_PATH
limit.
Add a new MAX_LONG_PATH constant and xutftowcs_long_path function for APIs
that support long paths.
While improved error checking is always active, long paths support must be
explicitly enabled via 'core.longpaths' option. This is to prevent end
users to shoot themselves in the foot by checking out files that Windows
Explorer, cmd/bash or their favorite IDE cannot handle.
Test suite:
Test the case is when the full pathname length of a dir is close
to 260 (MAX_PATH).
Bug report and an original reproducer by Andrey Rogozhnikov:
https://github.com/msysgit/git/pull/122#issuecomment-43604199
[jes: adjusted test number to avoid conflicts, added support for
chdir(), etc]
Thanks-to: Martin W. Kirst <maki@bitkings.de>
Thanks-to: Doug Kelly <dougk.ff7@gmail.com>
Original-test-by: Andrey Rogozhnikov <rogozhnikov.andrey@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2015-07-28 22:07:41 +03:00
|
|
|
struct repository;
|
|
|
|
int are_long_paths_enabled(void);
|
|
|
|
|
2019-09-04 14:09:48 +03:00
|
|
|
int mingw_core_config(const char *var, const char *value, void *cb);
|
2018-10-30 21:40:04 +03:00
|
|
|
#define platform_core_config mingw_core_config
|
|
|
|
|
2007-12-01 23:24:59 +03:00
|
|
|
/*
|
|
|
|
* things that are not available in header files
|
|
|
|
*/
|
|
|
|
|
2009-12-28 20:04:21 +03:00
|
|
|
typedef int uid_t;
|
2010-11-04 04:35:09 +03:00
|
|
|
typedef int socklen_t;
|
2016-01-14 19:51:59 +03:00
|
|
|
#ifndef __MINGW64_VERSION_MAJOR
|
|
|
|
typedef int pid_t;
|
2007-12-01 23:24:59 +03:00
|
|
|
#define hstrerror strerror
|
2016-01-14 19:51:59 +03:00
|
|
|
#endif
|
2007-12-01 23:24:59 +03:00
|
|
|
|
|
|
|
#define S_IFLNK 0120000 /* Symbolic link */
|
|
|
|
#define S_ISLNK(x) (((x) & S_IFMT) == S_IFLNK)
|
|
|
|
#define S_ISSOCK(x) 0
|
2009-12-28 20:13:52 +03:00
|
|
|
|
2016-01-15 16:24:29 +03:00
|
|
|
#ifndef S_IRWXG
|
2007-12-01 23:24:59 +03:00
|
|
|
#define S_IRGRP 0
|
|
|
|
#define S_IWGRP 0
|
|
|
|
#define S_IXGRP 0
|
2009-12-28 20:13:52 +03:00
|
|
|
#define S_IRWXG (S_IRGRP | S_IWGRP | S_IXGRP)
|
2016-01-15 16:24:29 +03:00
|
|
|
#endif
|
|
|
|
#ifndef S_IRWXO
|
2007-12-01 23:24:59 +03:00
|
|
|
#define S_IROTH 0
|
2009-12-28 20:13:52 +03:00
|
|
|
#define S_IWOTH 0
|
2007-12-01 23:24:59 +03:00
|
|
|
#define S_IXOTH 0
|
2009-12-28 20:13:52 +03:00
|
|
|
#define S_IRWXO (S_IROTH | S_IWOTH | S_IXOTH)
|
2016-01-15 16:24:29 +03:00
|
|
|
#endif
|
2012-04-17 22:00:04 +04:00
|
|
|
|
|
|
|
#define S_ISUID 0004000
|
|
|
|
#define S_ISGID 0002000
|
|
|
|
#define S_ISVTX 0001000
|
2007-12-01 23:24:59 +03:00
|
|
|
|
2009-07-04 23:26:38 +04:00
|
|
|
#define WIFEXITED(x) 1
|
|
|
|
#define WIFSIGNALED(x) 0
|
2007-12-01 23:24:59 +03:00
|
|
|
#define WEXITSTATUS(x) ((x) & 0xff)
|
2009-07-04 23:26:38 +04:00
|
|
|
#define WTERMSIG(x) SIGTERM
|
2007-12-01 23:24:59 +03:00
|
|
|
|
2013-09-11 03:22:34 +04:00
|
|
|
#ifndef EWOULDBLOCK
|
2010-10-12 20:39:41 +04:00
|
|
|
#define EWOULDBLOCK EAGAIN
|
2013-09-11 03:22:34 +04:00
|
|
|
#endif
|
2014-07-16 02:53:27 +04:00
|
|
|
#ifndef ELOOP
|
|
|
|
#define ELOOP EMLINK
|
|
|
|
#endif
|
2010-10-12 20:39:41 +04:00
|
|
|
#define SHUT_WR SD_SEND
|
|
|
|
|
2009-01-22 08:57:34 +03:00
|
|
|
#define SIGHUP 1
|
|
|
|
#define SIGQUIT 3
|
|
|
|
#define SIGKILL 9
|
|
|
|
#define SIGPIPE 13
|
|
|
|
#define SIGALRM 14
|
|
|
|
#define SIGCHLD 17
|
2007-12-01 23:24:59 +03:00
|
|
|
|
|
|
|
#define F_GETFD 1
|
|
|
|
#define F_SETFD 2
|
|
|
|
#define FD_CLOEXEC 0x1
|
|
|
|
|
2016-08-22 15:47:55 +03:00
|
|
|
#if !defined O_CLOEXEC && defined O_NOINHERIT
|
|
|
|
#define O_CLOEXEC O_NOINHERIT
|
|
|
|
#endif
|
|
|
|
|
2013-09-11 03:22:34 +04:00
|
|
|
#ifndef EAFNOSUPPORT
|
2010-11-04 04:35:09 +03:00
|
|
|
#define EAFNOSUPPORT WSAEAFNOSUPPORT
|
2013-09-11 03:22:34 +04:00
|
|
|
#endif
|
|
|
|
#ifndef ECONNABORTED
|
2010-11-04 04:35:09 +03:00
|
|
|
#define ECONNABORTED WSAECONNABORTED
|
2013-09-11 03:22:34 +04:00
|
|
|
#endif
|
2016-07-21 23:59:06 +03:00
|
|
|
#ifndef ENOTSOCK
|
|
|
|
#define ENOTSOCK WSAENOTSOCK
|
|
|
|
#endif
|
2010-11-04 04:35:09 +03:00
|
|
|
|
2007-12-01 23:24:59 +03:00
|
|
|
struct passwd {
|
|
|
|
char *pw_name;
|
|
|
|
char *pw_gecos;
|
|
|
|
char *pw_dir;
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef void (__cdecl *sig_handler_t)(int);
|
|
|
|
struct sigaction {
|
|
|
|
sig_handler_t sa_handler;
|
|
|
|
unsigned sa_flags;
|
|
|
|
};
|
|
|
|
#define SA_RESTART 0
|
|
|
|
|
|
|
|
struct itimerval {
|
|
|
|
struct timeval it_value, it_interval;
|
|
|
|
};
|
|
|
|
#define ITIMER_REAL 0
|
|
|
|
|
2015-03-08 13:12:45 +03:00
|
|
|
struct utsname {
|
|
|
|
char sysname[16];
|
|
|
|
char nodename[1];
|
|
|
|
char release[16];
|
|
|
|
char version[16];
|
|
|
|
char machine[1];
|
|
|
|
};
|
|
|
|
|
2010-09-27 15:01:59 +04:00
|
|
|
/*
|
|
|
|
* sanitize preprocessor namespace polluted by Windows headers defining
|
|
|
|
* macros which collide with git local versions
|
|
|
|
*/
|
|
|
|
#undef HELP_COMMAND /* from winuser.h */
|
|
|
|
|
2007-12-01 23:24:59 +03:00
|
|
|
/*
|
|
|
|
* trivial stubs
|
|
|
|
*/
|
|
|
|
|
|
|
|
static inline int fchmod(int fildes, mode_t mode)
|
|
|
|
{ errno = ENOSYS; return -1; }
|
2016-01-14 19:51:59 +03:00
|
|
|
#ifndef __MINGW64_VERSION_MAJOR
|
2011-11-16 03:39:33 +04:00
|
|
|
static inline pid_t fork(void)
|
|
|
|
{ errno = ENOSYS; return -1; }
|
2016-01-14 19:51:59 +03:00
|
|
|
#endif
|
2007-12-01 23:24:59 +03:00
|
|
|
static inline unsigned int alarm(unsigned int seconds)
|
|
|
|
{ return 0; }
|
|
|
|
static inline int fsync(int fd)
|
2010-05-20 22:57:54 +04:00
|
|
|
{ return _commit(fd); }
|
2007-12-01 23:24:59 +03:00
|
|
|
static inline void sync(void)
|
|
|
|
{}
|
2009-12-28 20:04:21 +03:00
|
|
|
static inline uid_t getuid(void)
|
2007-12-01 23:24:59 +03:00
|
|
|
{ return 1; }
|
|
|
|
static inline struct passwd *getpwnam(const char *name)
|
|
|
|
{ return NULL; }
|
2010-03-06 18:40:40 +03:00
|
|
|
static inline int fcntl(int fd, int cmd, ...)
|
2007-12-01 23:24:59 +03:00
|
|
|
{
|
|
|
|
if (cmd == F_GETFD || cmd == F_SETFD)
|
|
|
|
return 0;
|
|
|
|
errno = EINVAL;
|
|
|
|
return -1;
|
|
|
|
}
|
2019-02-23 01:25:01 +03:00
|
|
|
|
2014-09-22 22:24:34 +04:00
|
|
|
#define sigemptyset(x) (void)0
|
|
|
|
static inline int sigaddset(sigset_t *set, int signum)
|
|
|
|
{ return 0; }
|
2016-05-01 22:08:21 +03:00
|
|
|
#define SIG_BLOCK 0
|
2014-09-22 22:24:34 +04:00
|
|
|
#define SIG_UNBLOCK 0
|
|
|
|
static inline int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)
|
|
|
|
{ return 0; }
|
2015-04-15 21:29:30 +03:00
|
|
|
static inline pid_t getppid(void)
|
|
|
|
{ return 1; }
|
|
|
|
static inline pid_t getpgid(pid_t pid)
|
|
|
|
{ return pid == 0 ? getpid() : pid; }
|
|
|
|
static inline pid_t tcgetpgrp(int fd)
|
|
|
|
{ return getpid(); }
|
2007-12-01 23:24:59 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* simple adaptors
|
|
|
|
*/
|
|
|
|
|
2012-03-15 21:21:28 +04:00
|
|
|
int mingw_mkdir(const char *path, int mode);
|
2007-12-01 23:24:59 +03:00
|
|
|
#define mkdir mingw_mkdir
|
|
|
|
|
2010-11-04 04:35:14 +03:00
|
|
|
#define WNOHANG 1
|
2011-12-08 23:39:57 +04:00
|
|
|
pid_t waitpid(pid_t pid, int *status, int options);
|
2007-12-01 23:24:59 +03:00
|
|
|
|
2010-11-04 04:35:15 +03:00
|
|
|
#define kill mingw_kill
|
|
|
|
int mingw_kill(pid_t pid, int sig);
|
|
|
|
|
2009-10-19 19:42:07 +04:00
|
|
|
#ifndef NO_OPENSSL
|
|
|
|
#include <openssl/ssl.h>
|
|
|
|
static inline int mingw_SSL_set_fd(SSL *ssl, int fd)
|
|
|
|
{
|
|
|
|
return SSL_set_fd(ssl, _get_osfhandle(fd));
|
|
|
|
}
|
|
|
|
#define SSL_set_fd mingw_SSL_set_fd
|
|
|
|
|
|
|
|
static inline int mingw_SSL_set_rfd(SSL *ssl, int fd)
|
|
|
|
{
|
|
|
|
return SSL_set_rfd(ssl, _get_osfhandle(fd));
|
|
|
|
}
|
|
|
|
#define SSL_set_rfd mingw_SSL_set_rfd
|
|
|
|
|
|
|
|
static inline int mingw_SSL_set_wfd(SSL *ssl, int fd)
|
|
|
|
{
|
|
|
|
return SSL_set_wfd(ssl, _get_osfhandle(fd));
|
|
|
|
}
|
|
|
|
#define SSL_set_wfd mingw_SSL_set_wfd
|
|
|
|
#endif
|
|
|
|
|
2007-12-01 23:24:59 +03:00
|
|
|
/*
|
|
|
|
* implementations of missing functions
|
|
|
|
*/
|
|
|
|
|
Windows: A pipe() replacement whose ends are not inherited to children.
On Unix the idiom to use a pipe is as follows:
pipe(fd);
pid = fork();
if (!pid) {
dup2(fd[1], 1);
close(fd[1]);
close(fd[0]);
...
}
close(fd[1]);
i.e. the child process closes the both pipe ends after duplicating one
to the file descriptors where they are needed.
On Windows, which does not have fork(), we never have an opportunity to
(1) duplicate a pipe end in the child, (2) close unused pipe ends. Instead,
we must use this idiom:
save1 = dup(1);
pipe(fd);
dup2(fd[1], 1);
spawn(...);
dup2(save1, 1);
close(fd[1]);
i.e. save away the descriptor at the destination slot, replace by the pipe
end, spawn process, restore the saved file.
But there is a problem: Notice that the child did not only inherit the
dup2()ed descriptor, but also *both* original pipe ends. Although the one
end that was dup()ed could be closed before the spawn(), we cannot close
the other end - the child inherits it, no matter what.
The solution is to generate non-inheritable pipes. At the first glance,
this looks strange: The purpose of pipes is usually to be inherited to
child processes. But notice that in the course of actions as outlined
above, the pipe descriptor that we want to inherit to the child is
dup2()ed, and as it so happens, Windows's dup2() creates inheritable
duplicates.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
2007-12-08 00:05:36 +03:00
|
|
|
int pipe(int filedes[2]);
|
2007-12-01 23:24:59 +03:00
|
|
|
unsigned int sleep (unsigned int seconds);
|
|
|
|
int mkstemp(char *template);
|
|
|
|
int gettimeofday(struct timeval *tv, void *tz);
|
2016-01-14 19:51:59 +03:00
|
|
|
#ifndef __MINGW64_VERSION_MAJOR
|
2007-12-01 23:24:59 +03:00
|
|
|
struct tm *gmtime_r(const time_t *timep, struct tm *result);
|
|
|
|
struct tm *localtime_r(const time_t *timep, struct tm *result);
|
2016-01-14 19:51:59 +03:00
|
|
|
#endif
|
2007-12-01 23:24:59 +03:00
|
|
|
int getpagesize(void); /* defined in MinGW's libgcc.a */
|
2009-12-28 20:04:21 +03:00
|
|
|
struct passwd *getpwuid(uid_t uid);
|
2007-12-01 23:24:59 +03:00
|
|
|
int setitimer(int type, struct itimerval *in, struct itimerval *out);
|
|
|
|
int sigaction(int sig, struct sigaction *in, struct sigaction *out);
|
2009-01-24 17:04:39 +03:00
|
|
|
int link(const char *oldpath, const char *newpath);
|
2015-03-08 13:12:45 +03:00
|
|
|
int uname(struct utsname *buf);
|
2015-05-24 02:24:41 +03:00
|
|
|
int readlink(const char *path, char *buf, size_t bufsiz);
|
2019-02-11 16:19:18 +03:00
|
|
|
struct index_state;
|
|
|
|
int mingw_create_symlink(struct index_state *index, const char *target, const char *link);
|
|
|
|
#define create_symlink mingw_create_symlink
|
2007-12-03 23:55:57 +03:00
|
|
|
|
2008-03-05 23:51:27 +03:00
|
|
|
/*
|
|
|
|
* replacements of existing functions
|
|
|
|
*/
|
|
|
|
|
2011-02-07 23:49:33 +03:00
|
|
|
int mingw_unlink(const char *pathname);
|
|
|
|
#define unlink mingw_unlink
|
|
|
|
|
2011-02-07 23:52:34 +03:00
|
|
|
int mingw_rmdir(const char *path);
|
|
|
|
#define rmdir mingw_rmdir
|
|
|
|
|
2007-11-16 00:22:47 +03:00
|
|
|
int mingw_open (const char *filename, int oflags, ...);
|
|
|
|
#define open mingw_open
|
Makefile: add OPEN_RETURNS_EINTR knob
On some platforms, open() reportedly returns EINTR when opening regular
files and we receive a signal (usually SIGALRM from our progress meter).
This shouldn't happen, as open() should be a restartable syscall, and we
specify SA_RESTART when setting up the alarm handler. So it may actually
be a kernel or libc bug for this to happen. But it has been reported on
at least one version of Linux (on a network filesystem):
https://lore.kernel.org/git/c8061cce-71e4-17bd-a56a-a5fed93804da@neanderfunk.de/
as well as on macOS starting with Big Sur even on a regular filesystem.
We can work around it by retrying open() calls that get EINTR, just as
we do for read(), etc. Since we don't ever _want_ to interrupt an open()
call, we can get away with just redefining open, rather than insisting
all callsites use xopen().
We actually do have an xopen() wrapper already (and it even does this
retry, though there's no indication of it being an observed problem back
then; it seems simply to have been lifted from xread(), etc). But it is
used hardly anywhere, and isn't suitable for general use because it will
die() on error. In theory we could combine the two, but it's awkward to
do so because of the variable-args interface of open().
This patch adds a Makefile knob for enabling the workaround. It's not
enabled by default for any platforms in config.mak.uname yet, as we
don't have enough data to decide how common this is (I have not been
able to reproduce on either Linux or Big Sur myself). It may be worth
enabling preemptively anyway, since the cost is pretty low (if we don't
see an EINTR, it's just an extra conditional).
However, note that we must not enable this on Windows. It doesn't do
anything there, and the macro overrides the existing mingw_open()
redirection. I've added a preemptive #undef here in the mingw header
(which is processed first) to just quietly disable it (we could also
make it an #error, but there is little point in being so aggressive).
Reported-by: Aleksey Kliger <alklig@microsoft.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-26 09:14:35 +03:00
|
|
|
#undef OPEN_RETURNS_EINTR
|
2007-11-16 00:22:47 +03:00
|
|
|
|
2012-12-04 12:10:38 +04:00
|
|
|
int mingw_fgetc(FILE *stream);
|
|
|
|
#define fgetc mingw_fgetc
|
|
|
|
|
2010-02-25 23:03:44 +03:00
|
|
|
FILE *mingw_fopen (const char *filename, const char *otype);
|
|
|
|
#define fopen mingw_fopen
|
|
|
|
|
|
|
|
FILE *mingw_freopen (const char *filename, const char *otype, FILE *stream);
|
|
|
|
#define freopen mingw_freopen
|
|
|
|
|
2012-10-17 11:05:51 +04:00
|
|
|
int mingw_fflush(FILE *stream);
|
|
|
|
#define fflush mingw_fflush
|
|
|
|
|
2015-12-17 20:08:15 +03:00
|
|
|
ssize_t mingw_write(int fd, const void *buf, size_t len);
|
|
|
|
#define write mingw_write
|
|
|
|
|
2012-03-15 21:21:28 +04:00
|
|
|
int mingw_access(const char *filename, int mode);
|
|
|
|
#undef access
|
|
|
|
#define access mingw_access
|
|
|
|
|
|
|
|
int mingw_chdir(const char *dirname);
|
|
|
|
#define chdir mingw_chdir
|
|
|
|
|
|
|
|
int mingw_chmod(const char *filename, int mode);
|
|
|
|
#define chmod mingw_chmod
|
|
|
|
|
|
|
|
char *mingw_mktemp(char *template);
|
|
|
|
#define mktemp mingw_mktemp
|
|
|
|
|
2008-03-05 23:51:27 +03:00
|
|
|
char *mingw_getcwd(char *pointer, int len);
|
|
|
|
#define getcwd mingw_getcwd
|
|
|
|
|
mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8)
On Windows, the authoritative environment is encoded in UTF-16. In Git
for Windows, we convert that to UTF-8 (because UTF-16 is *such* a
foreign idea to Git that its source code is unprepared for it).
Previously, out of performance concerns, we converted the entire
environment to UTF-8 in one fell swoop at the beginning, and upon
putenv() and run_command() converted it back.
Having a private copy of the environment comes with its own perils: when
a library used by Git's source code tries to modify the environment, it
does not really work (in Git for Windows' case, libcurl, see
https://github.com/git-for-windows/git/compare/bcad1e6d58^...bcad1e6d58^2
for a glimpse of the issues).
Hence, it makes our environment handling substantially more robust if we
switch to on-the-fly-conversion in `getenv()`/`putenv()` calls. Based
on an initial version in the MSVC context by Jeff Hostetler, this patch
makes it so.
Surprisingly, this has a *positive* effect on speed: at the time when
the current code was written, we tested the performance, and there were
*so many* `getenv()` calls that it seemed better to convert everything
in one go. In the meantime, though, Git has obviously been cleaned up a
bit with regards to `getenv()` calls so that the Git processes spawned
by the test suite use an average of only 40 `getenv()`/`putenv()` calls
over the process lifetime.
Speaking of the entire test suite: the total time spent in the
re-encoding in the current code takes about 32.4 seconds (out of 113
minutes runtime), whereas the code introduced in this patch takes only
about 8.2 seconds in total. Not much, but it proves that we need not be
concerned about the performance impact introduced by this patch.
Helped-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-30 12:22:30 +03:00
|
|
|
#ifdef NO_UNSETENV
|
|
|
|
#error "NO_UNSETENV is incompatible with the Windows-specific startup code!"
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We bind *env() routines (even the mingw_ ones) to private mingw_ versions.
|
|
|
|
* These talk to the CRT using UNICODE/wchar_t, but maintain the original
|
|
|
|
* narrow-char API.
|
|
|
|
*
|
|
|
|
* Note that the MSCRT maintains both ANSI (getenv()) and UNICODE (_wgetenv())
|
|
|
|
* routines and stores both versions of each environment variable in parallel
|
|
|
|
* (and secretly updates both when you set one or the other), but it uses CP_ACP
|
|
|
|
* to do the conversion rather than CP_UTF8.
|
|
|
|
*
|
|
|
|
* Since everything in the git code base is UTF8, we define the mingw_ routines
|
|
|
|
* to access the CRT using the UNICODE routines and manually convert them to
|
|
|
|
* UTF8. This also avoids round-trip problems.
|
|
|
|
*
|
|
|
|
* This also helps with our linkage, since "_wenviron" is publicly exported
|
|
|
|
* from the CRT. But to access "_environ" we would have to statically link
|
|
|
|
* to the CRT (/MT).
|
|
|
|
*
|
|
|
|
* We require NO_SETENV (and let gitsetenv() call our mingw_putenv).
|
|
|
|
*/
|
|
|
|
#define getenv mingw_getenv
|
|
|
|
#define putenv mingw_putenv
|
|
|
|
#define unsetenv mingw_putenv
|
2008-06-22 13:35:21 +04:00
|
|
|
char *mingw_getenv(const char *name);
|
mingw: reencode environment variables on the fly (UTF-16 <-> UTF-8)
On Windows, the authoritative environment is encoded in UTF-16. In Git
for Windows, we convert that to UTF-8 (because UTF-16 is *such* a
foreign idea to Git that its source code is unprepared for it).
Previously, out of performance concerns, we converted the entire
environment to UTF-8 in one fell swoop at the beginning, and upon
putenv() and run_command() converted it back.
Having a private copy of the environment comes with its own perils: when
a library used by Git's source code tries to modify the environment, it
does not really work (in Git for Windows' case, libcurl, see
https://github.com/git-for-windows/git/compare/bcad1e6d58^...bcad1e6d58^2
for a glimpse of the issues).
Hence, it makes our environment handling substantially more robust if we
switch to on-the-fly-conversion in `getenv()`/`putenv()` calls. Based
on an initial version in the MSVC context by Jeff Hostetler, this patch
makes it so.
Surprisingly, this has a *positive* effect on speed: at the time when
the current code was written, we tested the performance, and there were
*so many* `getenv()` calls that it seemed better to convert everything
in one go. In the meantime, though, Git has obviously been cleaned up a
bit with regards to `getenv()` calls so that the Git processes spawned
by the test suite use an average of only 40 `getenv()`/`putenv()` calls
over the process lifetime.
Speaking of the entire test suite: the total time spent in the
re-encoding in the current code takes about 32.4 seconds (out of 113
minutes runtime), whereas the code introduced in this patch takes only
about 8.2 seconds in total. Not much, but it proves that we need not be
concerned about the performance impact introduced by this patch.
Helped-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-30 12:22:30 +03:00
|
|
|
int mingw_putenv(const char *name);
|
2008-06-22 13:35:21 +04:00
|
|
|
|
2011-10-15 18:05:20 +04:00
|
|
|
int mingw_gethostname(char *host, int namelen);
|
|
|
|
#define gethostname mingw_gethostname
|
|
|
|
|
2007-12-26 15:51:18 +03:00
|
|
|
struct hostent *mingw_gethostbyname(const char *host);
|
|
|
|
#define gethostbyname mingw_gethostbyname
|
|
|
|
|
2009-11-24 01:55:50 +03:00
|
|
|
int mingw_getaddrinfo(const char *node, const char *service,
|
|
|
|
const struct addrinfo *hints, struct addrinfo **res);
|
|
|
|
#define getaddrinfo mingw_getaddrinfo
|
|
|
|
|
2007-12-26 15:51:18 +03:00
|
|
|
int mingw_socket(int domain, int type, int protocol);
|
|
|
|
#define socket mingw_socket
|
|
|
|
|
|
|
|
int mingw_connect(int sockfd, struct sockaddr *sa, size_t sz);
|
|
|
|
#define connect mingw_connect
|
|
|
|
|
2010-11-04 04:35:09 +03:00
|
|
|
int mingw_bind(int sockfd, struct sockaddr *sa, size_t sz);
|
|
|
|
#define bind mingw_bind
|
|
|
|
|
|
|
|
int mingw_setsockopt(int sockfd, int lvl, int optname, void *optval, int optlen);
|
|
|
|
#define setsockopt mingw_setsockopt
|
|
|
|
|
2011-05-19 00:24:37 +04:00
|
|
|
int mingw_shutdown(int sockfd, int how);
|
|
|
|
#define shutdown mingw_shutdown
|
|
|
|
|
2010-11-04 04:35:09 +03:00
|
|
|
int mingw_listen(int sockfd, int backlog);
|
|
|
|
#define listen mingw_listen
|
|
|
|
|
|
|
|
int mingw_accept(int sockfd, struct sockaddr *sa, socklen_t *sz);
|
|
|
|
#define accept mingw_accept
|
|
|
|
|
2007-12-08 00:19:40 +03:00
|
|
|
int mingw_rename(const char*, const char*);
|
|
|
|
#define rename mingw_rename
|
|
|
|
|
2009-11-07 23:10:31 +03:00
|
|
|
#if defined(USE_WIN32_MMAP) || defined(_MSC_VER)
|
2009-03-13 18:50:45 +03:00
|
|
|
int mingw_getpagesize(void);
|
|
|
|
#define getpagesize mingw_getpagesize
|
|
|
|
#endif
|
|
|
|
|
2022-03-11 01:43:20 +03:00
|
|
|
int win32_fsync_no_flush(int fd);
|
|
|
|
#define fsync_no_flush win32_fsync_no_flush
|
|
|
|
|
2022-04-05 08:20:14 +03:00
|
|
|
#define FSYNC_COMPONENTS_PLATFORM_DEFAULT (FSYNC_COMPONENTS_DEFAULT | FSYNC_COMPONENT_LOOSE_OBJECT)
|
|
|
|
#define FSYNC_METHOD_DEFAULT (FSYNC_METHOD_BATCH)
|
|
|
|
|
2011-03-01 00:13:22 +03:00
|
|
|
struct rlimit {
|
|
|
|
unsigned int rlim_cur;
|
|
|
|
};
|
|
|
|
#define RLIMIT_NOFILE 0
|
|
|
|
|
|
|
|
static inline int getrlimit(int resource, struct rlimit *rlp)
|
|
|
|
{
|
|
|
|
if (resource != RLIMIT_NOFILE) {
|
|
|
|
errno = EINVAL;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
rlp->rlim_cur = 2048;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-06 04:09:35 +04:00
|
|
|
/*
|
|
|
|
* The unit of FILETIME is 100-nanoseconds since January 1, 1601, UTC.
|
|
|
|
* Returns the 100-nanoseconds ("hekto nanoseconds") since the epoch.
|
|
|
|
*/
|
|
|
|
static inline long long filetime_to_hnsec(const FILETIME *ft)
|
|
|
|
{
|
|
|
|
long long winTime = ((long long)ft->dwHighDateTime << 32) + ft->dwLowDateTime;
|
|
|
|
/* Windows to Unix Epoch conversion */
|
|
|
|
return winTime - 116444736000000000LL;
|
|
|
|
}
|
|
|
|
|
MSVC: fix stat definition hell
In msvc.h, there's a couple of stat related functions defined diffently
from mingw.h. When we remove these definitions, the only problem we get is
"warning C4005: '_stati64' : macro redefinition" for this line in mingw.h:
#define _stati64(x,y) mingw_stat(x,y)
The reason is that as of MSVCR80.dll (distributed with MSVC 2005), the
original _stati64 family of functions was renamed to _stat32i64, and the
former function names became macros (pointing to the appropriate function
based on the definition of _USE_32BIT_TIME_T).
Defining _stati64 works on MinGW because MinGW by default compiles against
the MSVCRT.DLL that is part of Windows (i.e. _stati64 is a function rather
than a macro).
Note: MinGW *can* compile for newer MSVC runtime versions, and MSVC
apparently can also compile for the Windows MSVCRT.DLL via the DDK (see
http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell ).
Remove the stat definitions from msvc.h, as they are not compiler related.
In mingw.h, determine the runtime version in use from the definitions of
_stati64 and _USE_32BIT_TIME_T, and define stat() accordingly.
This also fixes that stat() in MSVC builds still resolves to mingw_lstat()
instead of mingw_stat().
Signed-off-by: Karsten Blees <blees@dcon.de>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-11 03:23:13 +04:00
|
|
|
/*
|
2018-10-23 13:23:22 +03:00
|
|
|
* Use mingw specific stat()/lstat()/fstat() implementations on Windows,
|
|
|
|
* including our own struct stat with 64 bit st_size and nanosecond-precision
|
|
|
|
* file times.
|
2007-09-03 22:40:26 +04:00
|
|
|
*/
|
2016-01-14 19:51:59 +03:00
|
|
|
#ifndef __MINGW64_VERSION_MAJOR
|
2009-03-05 19:05:12 +03:00
|
|
|
#define off_t off64_t
|
|
|
|
#define lseek _lseeki64
|
2019-06-20 00:06:03 +03:00
|
|
|
#ifndef _MSC_VER
|
2018-10-23 13:23:22 +03:00
|
|
|
struct timespec {
|
|
|
|
time_t tv_sec;
|
|
|
|
long tv_nsec;
|
|
|
|
};
|
2016-01-14 19:51:59 +03:00
|
|
|
#endif
|
2019-06-20 00:06:03 +03:00
|
|
|
#endif
|
MSVC: fix stat definition hell
In msvc.h, there's a couple of stat related functions defined diffently
from mingw.h. When we remove these definitions, the only problem we get is
"warning C4005: '_stati64' : macro redefinition" for this line in mingw.h:
#define _stati64(x,y) mingw_stat(x,y)
The reason is that as of MSVCR80.dll (distributed with MSVC 2005), the
original _stati64 family of functions was renamed to _stat32i64, and the
former function names became macros (pointing to the appropriate function
based on the definition of _USE_32BIT_TIME_T).
Defining _stati64 works on MinGW because MinGW by default compiles against
the MSVCRT.DLL that is part of Windows (i.e. _stati64 is a function rather
than a macro).
Note: MinGW *can* compile for newer MSVC runtime versions, and MSVC
apparently can also compile for the Windows MSVCRT.DLL via the DDK (see
http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell ).
Remove the stat definitions from msvc.h, as they are not compiler related.
In mingw.h, determine the runtime version in use from the definitions of
_stati64 and _USE_32BIT_TIME_T, and define stat() accordingly.
This also fixes that stat() in MSVC builds still resolves to mingw_lstat()
instead of mingw_stat().
Signed-off-by: Karsten Blees <blees@dcon.de>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-11 03:23:13 +04:00
|
|
|
|
2013-07-06 04:09:35 +04:00
|
|
|
static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)
|
|
|
|
{
|
|
|
|
long long hnsec = filetime_to_hnsec(ft);
|
|
|
|
ts->tv_sec = (time_t)(hnsec / 10000000);
|
|
|
|
ts->tv_nsec = (hnsec % 10000000) * 100;
|
|
|
|
}
|
|
|
|
|
2018-10-23 13:23:22 +03:00
|
|
|
struct mingw_stat {
|
|
|
|
_dev_t st_dev;
|
|
|
|
_ino_t st_ino;
|
|
|
|
_mode_t st_mode;
|
|
|
|
short st_nlink;
|
|
|
|
short st_uid;
|
|
|
|
short st_gid;
|
|
|
|
_dev_t st_rdev;
|
|
|
|
off64_t st_size;
|
|
|
|
struct timespec st_atim;
|
|
|
|
struct timespec st_mtim;
|
|
|
|
struct timespec st_ctim;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define st_atime st_atim.tv_sec
|
|
|
|
#define st_mtime st_mtim.tv_sec
|
|
|
|
#define st_ctime st_ctim.tv_sec
|
|
|
|
|
2013-09-11 20:02:09 +04:00
|
|
|
#ifdef stat
|
|
|
|
#undef stat
|
|
|
|
#endif
|
2018-10-23 13:23:22 +03:00
|
|
|
#define stat mingw_stat
|
2008-08-19 00:01:06 +04:00
|
|
|
int mingw_lstat(const char *file_name, struct stat *buf);
|
2010-03-17 18:17:34 +03:00
|
|
|
int mingw_stat(const char *file_name, struct stat *buf);
|
2008-08-19 00:01:06 +04:00
|
|
|
int mingw_fstat(int fd, struct stat *buf);
|
2013-09-11 20:02:09 +04:00
|
|
|
#ifdef fstat
|
|
|
|
#undef fstat
|
|
|
|
#endif
|
2007-09-03 22:40:26 +04:00
|
|
|
#define fstat mingw_fstat
|
2013-09-11 20:02:09 +04:00
|
|
|
#ifdef lstat
|
|
|
|
#undef lstat
|
|
|
|
#endif
|
2013-09-08 16:21:30 +04:00
|
|
|
extern int (*lstat)(const char *file_name, struct stat *buf);
|
MSVC: fix stat definition hell
In msvc.h, there's a couple of stat related functions defined diffently
from mingw.h. When we remove these definitions, the only problem we get is
"warning C4005: '_stati64' : macro redefinition" for this line in mingw.h:
#define _stati64(x,y) mingw_stat(x,y)
The reason is that as of MSVCR80.dll (distributed with MSVC 2005), the
original _stati64 family of functions was renamed to _stat32i64, and the
former function names became macros (pointing to the appropriate function
based on the definition of _USE_32BIT_TIME_T).
Defining _stati64 works on MinGW because MinGW by default compiles against
the MSVCRT.DLL that is part of Windows (i.e. _stati64 is a function rather
than a macro).
Note: MinGW *can* compile for newer MSVC runtime versions, and MSVC
apparently can also compile for the Windows MSVCRT.DLL via the DDK (see
http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell ).
Remove the stat definitions from msvc.h, as they are not compiler related.
In mingw.h, determine the runtime version in use from the definitions of
_stati64 and _USE_32BIT_TIME_T, and define stat() accordingly.
This also fixes that stat() in MSVC builds still resolves to mingw_lstat()
instead of mingw_stat().
Signed-off-by: Karsten Blees <blees@dcon.de>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-11 03:23:13 +04:00
|
|
|
|
2007-09-03 22:40:26 +04:00
|
|
|
|
2007-09-07 15:05:00 +04:00
|
|
|
int mingw_utime(const char *file_name, const struct utimbuf *times);
|
|
|
|
#define utime mingw_utime
|
mingw: abort on invalid strftime formats
On Windows, strftime() does not silently ignore invalid formats, but
warns about them and then returns 0 and sets errno to EINVAL.
Unfortunately, Git does not expect such a behavior, as it disagrees
with strftime()'s semantics on Linux. As a consequence, Git
misinterprets the return value 0 as "I need more space" and grows the
buffer. As the larger buffer does not fix the format, the buffer grows
and grows and grows until we are out of memory and abort.
Ideally, we would switch off the parameter validation just for
strftime(), but we cannot even override the invalid parameter handler
via _set_thread_local_invalid_parameter_handler() using MINGW because
that function is not declared. Even _set_invalid_parameter_handler(),
which *is* declared, does not help, as it simply does... nothing.
So let's just bite the bullet and override strftime() for MINGW and
abort on an invalid format string. While this does not provide the
best user experience, it is the best we can do.
See https://msdn.microsoft.com/en-us/library/fe06s4ak.aspx for more
details.
This fixes https://github.com/git-for-windows/git/issues/863
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-19 19:49:22 +03:00
|
|
|
size_t mingw_strftime(char *s, size_t max,
|
|
|
|
const char *format, const struct tm *tm);
|
|
|
|
#define strftime mingw_strftime
|
2007-09-07 15:05:00 +04:00
|
|
|
|
Windows: avoid the "dup dance" when spawning a child process
When stdin, stdout, or stderr must be redirected for a child process that
on Windows is spawned using one of the spawn() functions of Microsoft's
C runtime, then there is no choice other than to
1. make a backup copy of fd 0,1,2 with dup
2. dup2 the redirection source fd into 0,1,2
3. spawn
4. dup2 the backup back into 0,1,2
5. close the backup copy and the redirection source
We used this idiom as well -- but we are not using the spawn() functions
anymore!
Instead, we have our own implementation. We had hardcoded that stdin,
stdout, and stderr of the child process were inherited from the parent's
fds 0, 1, and 2. But we can actually specify any fd.
With this patch, the fds to inherit are passed from start_command()'s
WIN32 section to our spawn implementation. This way, we can avoid the
backup copies of the fds.
The backup copies were a bug waiting to surface: The OS handles underlying
the dup()ed fds were inherited by the child process (but were not
associated with a file descriptor in the child). Consequently, the file or
pipe represented by the OS handle remained open even after the backup copy
was closed in the parent process until the child exited.
Since our implementation of pipe() creates non-inheritable OS handles, we
still dup() file descriptors in start_command() because dup() happens to
create inheritable duplicates. (A nice side effect is that the fd cleanup
in start_command is the same for Windows and Unix and remains unchanged.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-15 23:12:18 +03:00
|
|
|
pid_t mingw_spawnvpe(const char *cmd, const char **argv, char **env,
|
2010-04-12 00:40:12 +04:00
|
|
|
const char *dir,
|
Windows: avoid the "dup dance" when spawning a child process
When stdin, stdout, or stderr must be redirected for a child process that
on Windows is spawned using one of the spawn() functions of Microsoft's
C runtime, then there is no choice other than to
1. make a backup copy of fd 0,1,2 with dup
2. dup2 the redirection source fd into 0,1,2
3. spawn
4. dup2 the backup back into 0,1,2
5. close the backup copy and the redirection source
We used this idiom as well -- but we are not using the spawn() functions
anymore!
Instead, we have our own implementation. We had hardcoded that stdin,
stdout, and stderr of the child process were inherited from the parent's
fds 0, 1, and 2. But we can actually specify any fd.
With this patch, the fds to inherit are passed from start_command()'s
WIN32 section to our spawn implementation. This way, we can avoid the
backup copies of the fds.
The backup copies were a bug waiting to surface: The OS handles underlying
the dup()ed fds were inherited by the child process (but were not
associated with a file descriptor in the child). Consequently, the file or
pipe represented by the OS handle remained open even after the backup copy
was closed in the parent process until the child exited.
Since our implementation of pipe() creates non-inheritable OS handles, we
still dup() file descriptors in start_command() because dup() happens to
create inheritable duplicates. (A nice side effect is that the fd cleanup
in start_command is the same for Windows and Unix and remains unchanged.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-15 23:12:18 +03:00
|
|
|
int fhin, int fhout, int fherr);
|
2012-04-05 21:48:46 +04:00
|
|
|
int mingw_execvp(const char *cmd, char *const *argv);
|
2007-12-04 14:38:32 +03:00
|
|
|
#define execvp mingw_execvp
|
2012-04-05 21:48:46 +04:00
|
|
|
int mingw_execv(const char *cmd, char *const *argv);
|
2010-09-27 15:02:17 +04:00
|
|
|
#define execv mingw_execv
|
2007-12-04 14:38:32 +03:00
|
|
|
|
2007-11-17 21:16:53 +03:00
|
|
|
static inline unsigned int git_ntohl(unsigned int x)
|
|
|
|
{ return (unsigned int)ntohl(x); }
|
|
|
|
#define ntohl git_ntohl
|
|
|
|
|
2007-11-13 12:14:45 +03:00
|
|
|
sig_handler_t mingw_signal(int sig, sig_handler_t handler);
|
|
|
|
#define signal mingw_signal
|
|
|
|
|
2012-12-04 12:10:38 +04:00
|
|
|
int mingw_raise(int sig);
|
|
|
|
#define raise mingw_raise
|
|
|
|
|
2008-07-18 11:34:44 +04:00
|
|
|
/*
|
|
|
|
* ANSI emulation wrappers
|
|
|
|
*/
|
|
|
|
|
mingw: intercept isatty() to handle /dev/null as Git expects it
When Git's source code calls isatty(), it really asks whether the
respective file descriptor is connected to an interactive terminal.
Windows' _isatty() function, however, determines whether the file
descriptor is associated with a character device. And NUL, Windows'
equivalent of /dev/null, is a character device.
Which means that for years, Git mistakenly detected an associated
interactive terminal when being run through the test suite, which
almost always redirects stdin, stdout and stderr to /dev/null.
This bug only became obvious, and painfully so, when the new
bisect--helper entered the `pu` branch and made the automatic build & test
time out because t6030 was waiting for an answer.
For details, see
https://msdn.microsoft.com/en-us/library/f4s0ddew.aspx
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-11 14:16:57 +03:00
|
|
|
int winansi_isatty(int fd);
|
|
|
|
#define isatty winansi_isatty
|
|
|
|
|
2018-10-30 21:44:40 +03:00
|
|
|
int winansi_dup2(int oldfd, int newfd);
|
|
|
|
#define dup2 winansi_dup2
|
|
|
|
|
Win32: Thread-safe windows console output
Winansi.c has many static variables that are accessed and modified from
the [v][f]printf / fputs functions overridden in the file. This may cause
multi threaded git commands that print to the console to produce corrupted
output or even crash.
Additionally, winansi.c doesn't override all functions that can be used to
print to the console (e.g. fwrite, write, fputc are missing), so that ANSI
escapes don't work properly for some git commands (e.g. git-grep).
Instead of doing ANSI emulation in just a few wrapped functions on top of
the IO API, let's plug into the IO system and take advantage of the thread
safety inherent to the IO system.
Redirect stdout and stderr to a pipe if they point to the console. A
background thread reads from the pipe, handles ANSI escape sequences and
UTF-8 to UTF-16 conversion, then writes to the console.
The pipe-based stdout and stderr replacements must be set to unbuffered, as
MSVCRT doesn't support line buffering and fully buffered streams are
inappropriate for console output.
Due to the byte-oriented pipe, ANSI escape sequences and multi-byte UTF-8
sequences can no longer be expected to arrive in one piece. Replace the
string-based ansi_emulate() with a simple stateful parser (this also fixes
colored diff hunk headers, which were broken as of commit 2efcc977).
Override isatty to return true for the pipes redirecting to the console.
Exec/spawn obtain the original console handle to pass to the next process
via winansi_get_osfhandle().
All other overrides are gone, the default stdio implementations work as
expected with the piped stdout/stderr descriptors.
Global variables are either initialized on startup (single threaded) or
exclusively modified by the background thread. Threads communicate through
the pipe, no further synchronization is necessary.
The background thread is terminated by disonnecting the pipe after flushing
the stdio and pipe buffers. This doesn't work for anonymous pipes (created
via CreatePipe), as DisconnectNamedPipe only works on the read end, which
discards remaining data. Thus we have to setup the pipe manually, with the
write end beeing the server (opened with CreateNamedPipe) and the read end
the client (opened with CreateFile).
Limitations: doesn't track reopened or duped file descriptors, i.e.:
- fdopen(1/2) returns fully buffered streams
- dup(1/2), dup2(1/2) returns normal pipe descriptors (i.e. isatty() =
false, winansi_get_osfhandle won't return the original console handle)
Currently, only the git-format-patch command uses xfdopen(xdup(1)) (see
"realstdout" in builtin/log.c), but works well with these limitations.
Many thanks to Atsushi Nakagawa <atnak@chejz.com> for suggesting and
reviewing the thread-exit-mechanism.
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-15 01:24:19 +04:00
|
|
|
void winansi_init(void);
|
|
|
|
HANDLE winansi_get_osfhandle(int fd);
|
2008-07-18 11:34:44 +04:00
|
|
|
|
2007-12-03 23:55:57 +03:00
|
|
|
/*
|
|
|
|
* git specific compatibility
|
|
|
|
*/
|
|
|
|
|
2016-03-23 13:55:00 +03:00
|
|
|
static inline void convert_slashes(char *path)
|
|
|
|
{
|
|
|
|
for (; *path; path++)
|
|
|
|
if (*path == '\\')
|
|
|
|
*path = '/';
|
|
|
|
}
|
2018-12-07 15:39:30 +03:00
|
|
|
struct strbuf;
|
|
|
|
int mingw_is_mount_point(struct strbuf *path);
|
2018-12-11 14:17:49 +03:00
|
|
|
extern int (*win32_is_mount_point)(struct strbuf *path);
|
|
|
|
#define is_mount_point win32_is_mount_point
|
2018-12-11 14:55:26 +03:00
|
|
|
#define CAN_UNLINK_MOUNT_POINTS 1
|
2007-12-03 23:55:57 +03:00
|
|
|
#define PATH_SEP ';'
|
2019-09-04 14:09:48 +03:00
|
|
|
char *mingw_query_user_email(void);
|
2018-10-15 12:47:08 +03:00
|
|
|
#define query_user_email mingw_query_user_email
|
2020-01-31 13:49:04 +03:00
|
|
|
struct strbuf;
|
|
|
|
char *mingw_strbuf_realpath(struct strbuf *resolved, const char *path);
|
|
|
|
#define platform_strbuf_realpath mingw_strbuf_realpath
|
2016-03-30 14:37:36 +03:00
|
|
|
#if !defined(__MINGW64_VERSION_MAJOR) && (!defined(_MSC_VER) || _MSC_VER < 1800)
|
2007-03-23 12:57:05 +03:00
|
|
|
#define PRIuMAX "I64u"
|
2013-09-19 11:17:07 +04:00
|
|
|
#define PRId64 "I64d"
|
2016-01-14 19:51:59 +03:00
|
|
|
#else
|
|
|
|
#include <inttypes.h>
|
|
|
|
#endif
|
2007-12-08 00:08:59 +03:00
|
|
|
|
2022-03-02 13:06:24 +03:00
|
|
|
/**
|
|
|
|
* Verifies that the specified path is owned by the user running the
|
|
|
|
* current process.
|
|
|
|
*/
|
2022-08-08 16:27:47 +03:00
|
|
|
int is_path_owned_by_current_sid(const char *path, struct strbuf *report);
|
2022-03-02 13:06:24 +03:00
|
|
|
#define is_path_owned_by_current_user is_path_owned_by_current_sid
|
|
|
|
|
mingw: refuse to access paths with trailing spaces or periods
When creating a directory on Windows whose path ends in a space or a
period (or chains thereof), the Win32 API "helpfully" trims those. For
example, `mkdir("abc ");` will return success, but actually create a
directory called `abc` instead.
This stems back to the DOS days, when all file names had exactly 8
characters plus exactly 3 characters for the file extension, and the
only way to have shorter names was by padding with spaces.
Sadly, this "helpful" behavior is a bit inconsistent: after a successful
`mkdir("abc ");`, a `mkdir("abc /def")` will actually _fail_ (because
the directory `abc ` does not actually exist).
Even if it would work, we now have a serious problem because a Git
repository could contain directories `abc` and `abc `, and on Windows,
they would be "merged" unintentionally.
As these paths are illegal on Windows, anyway, let's disallow any
accesses to such paths on that Operating System.
For practical reasons, this behavior is still guarded by the
config setting `core.protectNTFS`: it is possible (and at least two
regression tests make use of it) to create commits without involving the
worktree. In such a scenario, it is of course possible -- even on
Windows -- to create such file names.
Among other consequences, this patch disallows submodules' paths to end
in spaces on Windows (which would formerly have confused Git enough to
try to write into incorrect paths, anyway).
While this patch does not fix a vulnerability on its own, it prevents an
attack vector that was exploited in demonstrations of a number of
recently-fixed security bugs.
The regression test added to `t/t7417-submodule-path-url.sh` reflects
that attack vector.
Note that we have to adjust the test case "prevent git~1 squatting on
Windows" in `t/t7415-submodule-names.sh` because of a very subtle issue.
It tries to clone two submodules whose names differ only in a trailing
period character, and as a consequence their git directories differ in
the same way. Previously, when Git tried to clone the second submodule,
it thought that the git directory already existed (because on Windows,
when you create a directory with the name `b.` it actually creates `b`),
but with this patch, the first submodule's clone will fail because of
the illegal name of the git directory. Therefore, when cloning the
second submodule, Git will take a different code path: a fresh clone
(without an existing git directory). Both code paths fail to clone the
second submodule, both because the the corresponding worktree directory
exists and is not empty, but the error messages are worded differently.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-09-05 14:27:53 +03:00
|
|
|
/**
|
|
|
|
* Verifies that the given path is a valid one on Windows.
|
|
|
|
*
|
mingw: refuse to access paths with illegal characters
Certain characters are not admissible in file names on Windows, even if
Cygwin/MSYS2 (and therefore, Git for Windows' Bash) pretend that they
are, e.g. `:`, `<`, `>`, etc
Let's disallow those characters explicitly in Windows builds of Git.
Note: just like trailing spaces or periods, it _is_ possible on Windows
to create commits adding files with such illegal characters, as long as
the operation leaves the worktree untouched. To allow for that, we
continue to guard `is_valid_win32_path()` behind the config setting
`core.protectNTFS`, so that users _can_ continue to do that, as long as
they turn the protections off via that config setting.
Among other problems, this prevents Git from trying to write to an "NTFS
Alternate Data Stream" (which refers to metadata stored alongside a
file, under a special name: "<filename>:<stream-name>"). This fix
therefore also prevents an attack vector that was exploited in
demonstrations of a number of recently-fixed security bugs.
Further reading on illegal characters in Win32 filenames:
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-09-05 14:44:21 +03:00
|
|
|
* In particular, path segments are disallowed which
|
|
|
|
*
|
|
|
|
* - end in a period or a space (except the special directories `.` and `..`).
|
|
|
|
*
|
|
|
|
* - contain any of the reserved characters, e.g. `:`, `;`, `*`, etc
|
mingw: refuse to access paths with trailing spaces or periods
When creating a directory on Windows whose path ends in a space or a
period (or chains thereof), the Win32 API "helpfully" trims those. For
example, `mkdir("abc ");` will return success, but actually create a
directory called `abc` instead.
This stems back to the DOS days, when all file names had exactly 8
characters plus exactly 3 characters for the file extension, and the
only way to have shorter names was by padding with spaces.
Sadly, this "helpful" behavior is a bit inconsistent: after a successful
`mkdir("abc ");`, a `mkdir("abc /def")` will actually _fail_ (because
the directory `abc ` does not actually exist).
Even if it would work, we now have a serious problem because a Git
repository could contain directories `abc` and `abc `, and on Windows,
they would be "merged" unintentionally.
As these paths are illegal on Windows, anyway, let's disallow any
accesses to such paths on that Operating System.
For practical reasons, this behavior is still guarded by the
config setting `core.protectNTFS`: it is possible (and at least two
regression tests make use of it) to create commits without involving the
worktree. In such a scenario, it is of course possible -- even on
Windows -- to create such file names.
Among other consequences, this patch disallows submodules' paths to end
in spaces on Windows (which would formerly have confused Git enough to
try to write into incorrect paths, anyway).
While this patch does not fix a vulnerability on its own, it prevents an
attack vector that was exploited in demonstrations of a number of
recently-fixed security bugs.
The regression test added to `t/t7417-submodule-path-url.sh` reflects
that attack vector.
Note that we have to adjust the test case "prevent git~1 squatting on
Windows" in `t/t7415-submodule-names.sh` because of a very subtle issue.
It tries to clone two submodules whose names differ only in a trailing
period character, and as a consequence their git directories differ in
the same way. Previously, when Git tried to clone the second submodule,
it thought that the git directory already existed (because on Windows,
when you create a directory with the name `b.` it actually creates `b`),
but with this patch, the first submodule's clone will fail because of
the illegal name of the git directory. Therefore, when cloning the
second submodule, Git will take a different code path: a fresh clone
(without an existing git directory). Both code paths fail to clone the
second submodule, both because the the corresponding worktree directory
exists and is not empty, but the error messages are worded differently.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-09-05 14:27:53 +03:00
|
|
|
*
|
2019-12-22 01:05:01 +03:00
|
|
|
* - correspond to reserved names (such as `AUX`, `PRN`, etc)
|
|
|
|
*
|
|
|
|
* The `allow_literal_nul` parameter controls whether the path `NUL` should
|
|
|
|
* be considered valid (this makes sense e.g. before opening files, as it is
|
|
|
|
* perfectly legitimate to open `NUL` on Windows, just as it is to open
|
|
|
|
* `/dev/null` on Unix/Linux).
|
|
|
|
*
|
mingw: refuse to access paths with trailing spaces or periods
When creating a directory on Windows whose path ends in a space or a
period (or chains thereof), the Win32 API "helpfully" trims those. For
example, `mkdir("abc ");` will return success, but actually create a
directory called `abc` instead.
This stems back to the DOS days, when all file names had exactly 8
characters plus exactly 3 characters for the file extension, and the
only way to have shorter names was by padding with spaces.
Sadly, this "helpful" behavior is a bit inconsistent: after a successful
`mkdir("abc ");`, a `mkdir("abc /def")` will actually _fail_ (because
the directory `abc ` does not actually exist).
Even if it would work, we now have a serious problem because a Git
repository could contain directories `abc` and `abc `, and on Windows,
they would be "merged" unintentionally.
As these paths are illegal on Windows, anyway, let's disallow any
accesses to such paths on that Operating System.
For practical reasons, this behavior is still guarded by the
config setting `core.protectNTFS`: it is possible (and at least two
regression tests make use of it) to create commits without involving the
worktree. In such a scenario, it is of course possible -- even on
Windows -- to create such file names.
Among other consequences, this patch disallows submodules' paths to end
in spaces on Windows (which would formerly have confused Git enough to
try to write into incorrect paths, anyway).
While this patch does not fix a vulnerability on its own, it prevents an
attack vector that was exploited in demonstrations of a number of
recently-fixed security bugs.
The regression test added to `t/t7417-submodule-path-url.sh` reflects
that attack vector.
Note that we have to adjust the test case "prevent git~1 squatting on
Windows" in `t/t7415-submodule-names.sh` because of a very subtle issue.
It tries to clone two submodules whose names differ only in a trailing
period character, and as a consequence their git directories differ in
the same way. Previously, when Git tried to clone the second submodule,
it thought that the git directory already existed (because on Windows,
when you create a directory with the name `b.` it actually creates `b`),
but with this patch, the first submodule's clone will fail because of
the illegal name of the git directory. Therefore, when cloning the
second submodule, Git will take a different code path: a fresh clone
(without an existing git directory). Both code paths fail to clone the
second submodule, both because the the corresponding worktree directory
exists and is not empty, but the error messages are worded differently.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-09-05 14:27:53 +03:00
|
|
|
* Returns 1 upon success, otherwise 0.
|
|
|
|
*/
|
2019-12-22 01:05:01 +03:00
|
|
|
int is_valid_win32_path(const char *path, int allow_literal_nul);
|
|
|
|
#define is_valid_path(path) is_valid_win32_path(path, 0)
|
mingw: refuse to access paths with trailing spaces or periods
When creating a directory on Windows whose path ends in a space or a
period (or chains thereof), the Win32 API "helpfully" trims those. For
example, `mkdir("abc ");` will return success, but actually create a
directory called `abc` instead.
This stems back to the DOS days, when all file names had exactly 8
characters plus exactly 3 characters for the file extension, and the
only way to have shorter names was by padding with spaces.
Sadly, this "helpful" behavior is a bit inconsistent: after a successful
`mkdir("abc ");`, a `mkdir("abc /def")` will actually _fail_ (because
the directory `abc ` does not actually exist).
Even if it would work, we now have a serious problem because a Git
repository could contain directories `abc` and `abc `, and on Windows,
they would be "merged" unintentionally.
As these paths are illegal on Windows, anyway, let's disallow any
accesses to such paths on that Operating System.
For practical reasons, this behavior is still guarded by the
config setting `core.protectNTFS`: it is possible (and at least two
regression tests make use of it) to create commits without involving the
worktree. In such a scenario, it is of course possible -- even on
Windows -- to create such file names.
Among other consequences, this patch disallows submodules' paths to end
in spaces on Windows (which would formerly have confused Git enough to
try to write into incorrect paths, anyway).
While this patch does not fix a vulnerability on its own, it prevents an
attack vector that was exploited in demonstrations of a number of
recently-fixed security bugs.
The regression test added to `t/t7417-submodule-path-url.sh` reflects
that attack vector.
Note that we have to adjust the test case "prevent git~1 squatting on
Windows" in `t/t7415-submodule-names.sh` because of a very subtle issue.
It tries to clone two submodules whose names differ only in a trailing
period character, and as a consequence their git directories differ in
the same way. Previously, when Git tried to clone the second submodule,
it thought that the git directory already existed (because on Windows,
when you create a directory with the name `b.` it actually creates `b`),
but with this patch, the first submodule's clone will fail because of
the illegal name of the git directory. Therefore, when cloning the
second submodule, Git will take a different code path: a fresh clone
(without an existing git directory). Both code paths fail to clone the
second submodule, both because the the corresponding worktree directory
exists and is not empty, but the error messages are worded differently.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2019-09-05 14:27:53 +03:00
|
|
|
|
mingw: support long paths
Windows paths are typically limited to MAX_PATH = 260 characters, even
though the underlying NTFS file system supports paths up to 32,767 chars.
This limitation is also evident in Windows Explorer, cmd.exe and many
other applications (including IDEs).
Particularly annoying is that most Windows APIs return bogus error codes
if a relative path only barely exceeds MAX_PATH in conjunction with the
current directory, e.g. ERROR_PATH_NOT_FOUND / ENOENT instead of the
infinitely more helpful ERROR_FILENAME_EXCED_RANGE / ENAMETOOLONG.
Many Windows wide char APIs support longer than MAX_PATH paths through the
file namespace prefix ('\\?\' or '\\?\UNC\') followed by an absolute path.
Notable exceptions include functions dealing with executables and the
current directory (CreateProcess, LoadLibrary, Get/SetCurrentDirectory) as
well as the entire shell API (ShellExecute, SHGetSpecialFolderPath...).
Introduce a handle_long_path function to check the length of a specified
path properly (and fail with ENAMETOOLONG), and to optionally expand long
paths using the '\\?\' file namespace prefix. Short paths will not be
modified, so we don't need to worry about device names (NUL, CON, AUX).
Contrary to MSDN docs, the GetFullPathNameW function doesn't seem to be
limited to MAX_PATH (at least not on Win7), so we can use it to do the
heavy lifting of the conversion (translate '/' to '\', eliminate '.' and
'..', and make an absolute path).
Add long path error checking to xutftowcs_path for APIs with hard MAX_PATH
limit.
Add a new MAX_LONG_PATH constant and xutftowcs_long_path function for APIs
that support long paths.
While improved error checking is always active, long paths support must be
explicitly enabled via 'core.longpaths' option. This is to prevent end
users to shoot themselves in the foot by checking out files that Windows
Explorer, cmd/bash or their favorite IDE cannot handle.
Test suite:
Test the case is when the full pathname length of a dir is close
to 260 (MAX_PATH).
Bug report and an original reproducer by Andrey Rogozhnikov:
https://github.com/msysgit/git/pull/122#issuecomment-43604199
[jes: adjusted test number to avoid conflicts, added support for
chdir(), etc]
Thanks-to: Martin W. Kirst <maki@bitkings.de>
Thanks-to: Doug Kelly <dougk.ff7@gmail.com>
Original-test-by: Andrey Rogozhnikov <rogozhnikov.andrey@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2015-07-28 22:07:41 +03:00
|
|
|
/**
|
|
|
|
* Max length of long paths (exceeding MAX_PATH). The actual maximum supported
|
|
|
|
* by NTFS is 32,767 (* sizeof(wchar_t)), but we choose an arbitrary smaller
|
|
|
|
* value to limit required stack memory.
|
|
|
|
*/
|
|
|
|
#define MAX_LONG_PATH 4096
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Handles paths that would exceed the MAX_PATH limit of Windows Unicode APIs.
|
|
|
|
*
|
|
|
|
* With expand == false, the function checks for over-long paths and fails
|
|
|
|
* with ENAMETOOLONG. The path parameter is not modified, except if cwd + path
|
|
|
|
* exceeds max_path, but the resulting absolute path doesn't (e.g. due to
|
|
|
|
* eliminating '..' components). The path parameter must point to a buffer
|
|
|
|
* of max_path wide characters.
|
|
|
|
*
|
|
|
|
* With expand == true, an over-long path is automatically converted in place
|
|
|
|
* to an absolute path prefixed with '\\?\', and the new length is returned.
|
|
|
|
* The path parameter must point to a buffer of MAX_LONG_PATH wide characters.
|
|
|
|
*
|
|
|
|
* Parameters:
|
|
|
|
* path: path to check and / or convert
|
|
|
|
* len: size of path on input (number of wide chars without \0)
|
|
|
|
* max_path: max short path length to check (usually MAX_PATH = 260, but just
|
|
|
|
* 248 for CreateDirectoryW)
|
|
|
|
* expand: false to only check the length, true to expand the path to a
|
|
|
|
* '\\?\'-prefixed absolute path
|
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* length of the resulting path, or -1 on failure
|
|
|
|
*
|
|
|
|
* Errors:
|
|
|
|
* ENAMETOOLONG if path is too long
|
|
|
|
*/
|
|
|
|
int handle_long_path(wchar_t *path, int len, int max_path, int expand);
|
|
|
|
|
2011-11-26 00:05:06 +04:00
|
|
|
/**
|
|
|
|
* Converts UTF-8 encoded string to UTF-16LE.
|
|
|
|
*
|
|
|
|
* To support repositories with legacy-encoded file names, invalid UTF-8 bytes
|
|
|
|
* 0xa0 - 0xff are converted to corresponding printable Unicode chars \u00a0 -
|
|
|
|
* \u00ff, and invalid UTF-8 bytes 0x80 - 0x9f (which would make non-printable
|
|
|
|
* Unicode) are converted to hex-code.
|
|
|
|
*
|
|
|
|
* Lead-bytes not followed by an appropriate number of trail-bytes, over-long
|
|
|
|
* encodings and 4-byte encodings > \u10ffff are detected as invalid UTF-8.
|
|
|
|
*
|
|
|
|
* Maximum space requirement for the target buffer is two wide chars per UTF-8
|
|
|
|
* char (((strlen(utf) * 2) + 1) [* sizeof(wchar_t)]).
|
|
|
|
*
|
|
|
|
* The maximum space is needed only if the entire input string consists of
|
|
|
|
* invalid UTF-8 bytes in range 0x80-0x9f, as per the following table:
|
|
|
|
*
|
|
|
|
* | | UTF-8 | UTF-16 |
|
|
|
|
* Code point | UTF-8 sequence | bytes | words | ratio
|
|
|
|
* --------------+-------------------+-------+--------+-------
|
|
|
|
* 000000-00007f | 0-7f | 1 | 1 | 1
|
|
|
|
* 000080-0007ff | c2-df + 80-bf | 2 | 1 | 0.5
|
|
|
|
* 000800-00ffff | e0-ef + 2 * 80-bf | 3 | 1 | 0.33
|
|
|
|
* 010000-10ffff | f0-f4 + 3 * 80-bf | 4 | 2 (a) | 0.5
|
|
|
|
* invalid | 80-9f | 1 | 2 (b) | 2
|
|
|
|
* invalid | a0-ff | 1 | 1 | 1
|
|
|
|
*
|
|
|
|
* (a) encoded as UTF-16 surrogate pair
|
|
|
|
* (b) encoded as two hex digits
|
|
|
|
*
|
|
|
|
* Note that, while the UTF-8 encoding scheme can be extended to 5-byte, 6-byte
|
|
|
|
* or even indefinite-byte sequences, the largest valid code point \u10ffff
|
|
|
|
* encodes as only 4 UTF-8 bytes.
|
|
|
|
*
|
|
|
|
* Parameters:
|
|
|
|
* wcs: wide char target buffer
|
|
|
|
* utf: string to convert
|
|
|
|
* wcslen: size of target buffer (in wchar_t's)
|
|
|
|
* utflen: size of string to convert, or -1 if 0-terminated
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* length of converted string (_wcslen(wcs)), or -1 on failure
|
|
|
|
*
|
|
|
|
* Errors:
|
|
|
|
* EINVAL: one of the input parameters is invalid (e.g. NULL)
|
|
|
|
* ERANGE: the output buffer is too small
|
|
|
|
*/
|
|
|
|
int xutftowcsn(wchar_t *wcs, const char *utf, size_t wcslen, int utflen);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Simplified variant of xutftowcsn, assumes input string is \0-terminated.
|
|
|
|
*/
|
|
|
|
static inline int xutftowcs(wchar_t *wcs, const char *utf, size_t wcslen)
|
|
|
|
{
|
|
|
|
return xutftowcsn(wcs, utf, wcslen, -1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
mingw: support long paths
Windows paths are typically limited to MAX_PATH = 260 characters, even
though the underlying NTFS file system supports paths up to 32,767 chars.
This limitation is also evident in Windows Explorer, cmd.exe and many
other applications (including IDEs).
Particularly annoying is that most Windows APIs return bogus error codes
if a relative path only barely exceeds MAX_PATH in conjunction with the
current directory, e.g. ERROR_PATH_NOT_FOUND / ENOENT instead of the
infinitely more helpful ERROR_FILENAME_EXCED_RANGE / ENAMETOOLONG.
Many Windows wide char APIs support longer than MAX_PATH paths through the
file namespace prefix ('\\?\' or '\\?\UNC\') followed by an absolute path.
Notable exceptions include functions dealing with executables and the
current directory (CreateProcess, LoadLibrary, Get/SetCurrentDirectory) as
well as the entire shell API (ShellExecute, SHGetSpecialFolderPath...).
Introduce a handle_long_path function to check the length of a specified
path properly (and fail with ENAMETOOLONG), and to optionally expand long
paths using the '\\?\' file namespace prefix. Short paths will not be
modified, so we don't need to worry about device names (NUL, CON, AUX).
Contrary to MSDN docs, the GetFullPathNameW function doesn't seem to be
limited to MAX_PATH (at least not on Win7), so we can use it to do the
heavy lifting of the conversion (translate '/' to '\', eliminate '.' and
'..', and make an absolute path).
Add long path error checking to xutftowcs_path for APIs with hard MAX_PATH
limit.
Add a new MAX_LONG_PATH constant and xutftowcs_long_path function for APIs
that support long paths.
While improved error checking is always active, long paths support must be
explicitly enabled via 'core.longpaths' option. This is to prevent end
users to shoot themselves in the foot by checking out files that Windows
Explorer, cmd/bash or their favorite IDE cannot handle.
Test suite:
Test the case is when the full pathname length of a dir is close
to 260 (MAX_PATH).
Bug report and an original reproducer by Andrey Rogozhnikov:
https://github.com/msysgit/git/pull/122#issuecomment-43604199
[jes: adjusted test number to avoid conflicts, added support for
chdir(), etc]
Thanks-to: Martin W. Kirst <maki@bitkings.de>
Thanks-to: Doug Kelly <dougk.ff7@gmail.com>
Original-test-by: Andrey Rogozhnikov <rogozhnikov.andrey@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2015-07-28 22:07:41 +03:00
|
|
|
* Simplified file system specific wrapper of xutftowcsn and handle_long_path.
|
|
|
|
* Converts ERANGE to ENAMETOOLONG. If expand is true, wcs must be at least
|
|
|
|
* MAX_LONG_PATH wide chars (see handle_long_path).
|
2011-11-26 00:05:06 +04:00
|
|
|
*/
|
mingw: support long paths
Windows paths are typically limited to MAX_PATH = 260 characters, even
though the underlying NTFS file system supports paths up to 32,767 chars.
This limitation is also evident in Windows Explorer, cmd.exe and many
other applications (including IDEs).
Particularly annoying is that most Windows APIs return bogus error codes
if a relative path only barely exceeds MAX_PATH in conjunction with the
current directory, e.g. ERROR_PATH_NOT_FOUND / ENOENT instead of the
infinitely more helpful ERROR_FILENAME_EXCED_RANGE / ENAMETOOLONG.
Many Windows wide char APIs support longer than MAX_PATH paths through the
file namespace prefix ('\\?\' or '\\?\UNC\') followed by an absolute path.
Notable exceptions include functions dealing with executables and the
current directory (CreateProcess, LoadLibrary, Get/SetCurrentDirectory) as
well as the entire shell API (ShellExecute, SHGetSpecialFolderPath...).
Introduce a handle_long_path function to check the length of a specified
path properly (and fail with ENAMETOOLONG), and to optionally expand long
paths using the '\\?\' file namespace prefix. Short paths will not be
modified, so we don't need to worry about device names (NUL, CON, AUX).
Contrary to MSDN docs, the GetFullPathNameW function doesn't seem to be
limited to MAX_PATH (at least not on Win7), so we can use it to do the
heavy lifting of the conversion (translate '/' to '\', eliminate '.' and
'..', and make an absolute path).
Add long path error checking to xutftowcs_path for APIs with hard MAX_PATH
limit.
Add a new MAX_LONG_PATH constant and xutftowcs_long_path function for APIs
that support long paths.
While improved error checking is always active, long paths support must be
explicitly enabled via 'core.longpaths' option. This is to prevent end
users to shoot themselves in the foot by checking out files that Windows
Explorer, cmd/bash or their favorite IDE cannot handle.
Test suite:
Test the case is when the full pathname length of a dir is close
to 260 (MAX_PATH).
Bug report and an original reproducer by Andrey Rogozhnikov:
https://github.com/msysgit/git/pull/122#issuecomment-43604199
[jes: adjusted test number to avoid conflicts, added support for
chdir(), etc]
Thanks-to: Martin W. Kirst <maki@bitkings.de>
Thanks-to: Doug Kelly <dougk.ff7@gmail.com>
Original-test-by: Andrey Rogozhnikov <rogozhnikov.andrey@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2015-07-28 22:07:41 +03:00
|
|
|
static inline int xutftowcs_path_ex(wchar_t *wcs, const char *utf,
|
|
|
|
size_t wcslen, int utflen, int max_path, int expand)
|
2011-11-26 00:05:06 +04:00
|
|
|
{
|
mingw: support long paths
Windows paths are typically limited to MAX_PATH = 260 characters, even
though the underlying NTFS file system supports paths up to 32,767 chars.
This limitation is also evident in Windows Explorer, cmd.exe and many
other applications (including IDEs).
Particularly annoying is that most Windows APIs return bogus error codes
if a relative path only barely exceeds MAX_PATH in conjunction with the
current directory, e.g. ERROR_PATH_NOT_FOUND / ENOENT instead of the
infinitely more helpful ERROR_FILENAME_EXCED_RANGE / ENAMETOOLONG.
Many Windows wide char APIs support longer than MAX_PATH paths through the
file namespace prefix ('\\?\' or '\\?\UNC\') followed by an absolute path.
Notable exceptions include functions dealing with executables and the
current directory (CreateProcess, LoadLibrary, Get/SetCurrentDirectory) as
well as the entire shell API (ShellExecute, SHGetSpecialFolderPath...).
Introduce a handle_long_path function to check the length of a specified
path properly (and fail with ENAMETOOLONG), and to optionally expand long
paths using the '\\?\' file namespace prefix. Short paths will not be
modified, so we don't need to worry about device names (NUL, CON, AUX).
Contrary to MSDN docs, the GetFullPathNameW function doesn't seem to be
limited to MAX_PATH (at least not on Win7), so we can use it to do the
heavy lifting of the conversion (translate '/' to '\', eliminate '.' and
'..', and make an absolute path).
Add long path error checking to xutftowcs_path for APIs with hard MAX_PATH
limit.
Add a new MAX_LONG_PATH constant and xutftowcs_long_path function for APIs
that support long paths.
While improved error checking is always active, long paths support must be
explicitly enabled via 'core.longpaths' option. This is to prevent end
users to shoot themselves in the foot by checking out files that Windows
Explorer, cmd/bash or their favorite IDE cannot handle.
Test suite:
Test the case is when the full pathname length of a dir is close
to 260 (MAX_PATH).
Bug report and an original reproducer by Andrey Rogozhnikov:
https://github.com/msysgit/git/pull/122#issuecomment-43604199
[jes: adjusted test number to avoid conflicts, added support for
chdir(), etc]
Thanks-to: Martin W. Kirst <maki@bitkings.de>
Thanks-to: Doug Kelly <dougk.ff7@gmail.com>
Original-test-by: Andrey Rogozhnikov <rogozhnikov.andrey@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2015-07-28 22:07:41 +03:00
|
|
|
int result = xutftowcsn(wcs, utf, wcslen, utflen);
|
2011-11-26 00:05:06 +04:00
|
|
|
if (result < 0 && errno == ERANGE)
|
|
|
|
errno = ENAMETOOLONG;
|
mingw: support long paths
Windows paths are typically limited to MAX_PATH = 260 characters, even
though the underlying NTFS file system supports paths up to 32,767 chars.
This limitation is also evident in Windows Explorer, cmd.exe and many
other applications (including IDEs).
Particularly annoying is that most Windows APIs return bogus error codes
if a relative path only barely exceeds MAX_PATH in conjunction with the
current directory, e.g. ERROR_PATH_NOT_FOUND / ENOENT instead of the
infinitely more helpful ERROR_FILENAME_EXCED_RANGE / ENAMETOOLONG.
Many Windows wide char APIs support longer than MAX_PATH paths through the
file namespace prefix ('\\?\' or '\\?\UNC\') followed by an absolute path.
Notable exceptions include functions dealing with executables and the
current directory (CreateProcess, LoadLibrary, Get/SetCurrentDirectory) as
well as the entire shell API (ShellExecute, SHGetSpecialFolderPath...).
Introduce a handle_long_path function to check the length of a specified
path properly (and fail with ENAMETOOLONG), and to optionally expand long
paths using the '\\?\' file namespace prefix. Short paths will not be
modified, so we don't need to worry about device names (NUL, CON, AUX).
Contrary to MSDN docs, the GetFullPathNameW function doesn't seem to be
limited to MAX_PATH (at least not on Win7), so we can use it to do the
heavy lifting of the conversion (translate '/' to '\', eliminate '.' and
'..', and make an absolute path).
Add long path error checking to xutftowcs_path for APIs with hard MAX_PATH
limit.
Add a new MAX_LONG_PATH constant and xutftowcs_long_path function for APIs
that support long paths.
While improved error checking is always active, long paths support must be
explicitly enabled via 'core.longpaths' option. This is to prevent end
users to shoot themselves in the foot by checking out files that Windows
Explorer, cmd/bash or their favorite IDE cannot handle.
Test suite:
Test the case is when the full pathname length of a dir is close
to 260 (MAX_PATH).
Bug report and an original reproducer by Andrey Rogozhnikov:
https://github.com/msysgit/git/pull/122#issuecomment-43604199
[jes: adjusted test number to avoid conflicts, added support for
chdir(), etc]
Thanks-to: Martin W. Kirst <maki@bitkings.de>
Thanks-to: Doug Kelly <dougk.ff7@gmail.com>
Original-test-by: Andrey Rogozhnikov <rogozhnikov.andrey@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2015-07-28 22:07:41 +03:00
|
|
|
if (result >= 0)
|
|
|
|
result = handle_long_path(wcs, result, max_path, expand);
|
2011-11-26 00:05:06 +04:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
mingw: support long paths
Windows paths are typically limited to MAX_PATH = 260 characters, even
though the underlying NTFS file system supports paths up to 32,767 chars.
This limitation is also evident in Windows Explorer, cmd.exe and many
other applications (including IDEs).
Particularly annoying is that most Windows APIs return bogus error codes
if a relative path only barely exceeds MAX_PATH in conjunction with the
current directory, e.g. ERROR_PATH_NOT_FOUND / ENOENT instead of the
infinitely more helpful ERROR_FILENAME_EXCED_RANGE / ENAMETOOLONG.
Many Windows wide char APIs support longer than MAX_PATH paths through the
file namespace prefix ('\\?\' or '\\?\UNC\') followed by an absolute path.
Notable exceptions include functions dealing with executables and the
current directory (CreateProcess, LoadLibrary, Get/SetCurrentDirectory) as
well as the entire shell API (ShellExecute, SHGetSpecialFolderPath...).
Introduce a handle_long_path function to check the length of a specified
path properly (and fail with ENAMETOOLONG), and to optionally expand long
paths using the '\\?\' file namespace prefix. Short paths will not be
modified, so we don't need to worry about device names (NUL, CON, AUX).
Contrary to MSDN docs, the GetFullPathNameW function doesn't seem to be
limited to MAX_PATH (at least not on Win7), so we can use it to do the
heavy lifting of the conversion (translate '/' to '\', eliminate '.' and
'..', and make an absolute path).
Add long path error checking to xutftowcs_path for APIs with hard MAX_PATH
limit.
Add a new MAX_LONG_PATH constant and xutftowcs_long_path function for APIs
that support long paths.
While improved error checking is always active, long paths support must be
explicitly enabled via 'core.longpaths' option. This is to prevent end
users to shoot themselves in the foot by checking out files that Windows
Explorer, cmd/bash or their favorite IDE cannot handle.
Test suite:
Test the case is when the full pathname length of a dir is close
to 260 (MAX_PATH).
Bug report and an original reproducer by Andrey Rogozhnikov:
https://github.com/msysgit/git/pull/122#issuecomment-43604199
[jes: adjusted test number to avoid conflicts, added support for
chdir(), etc]
Thanks-to: Martin W. Kirst <maki@bitkings.de>
Thanks-to: Doug Kelly <dougk.ff7@gmail.com>
Original-test-by: Andrey Rogozhnikov <rogozhnikov.andrey@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2015-07-28 22:07:41 +03:00
|
|
|
/**
|
|
|
|
* Simplified file system specific variant of xutftowcsn, assumes output
|
|
|
|
* buffer size is MAX_PATH wide chars and input string is \0-terminated,
|
|
|
|
* fails with ENAMETOOLONG if input string is too long. Typically used for
|
|
|
|
* Windows APIs that don't support long paths, e.g. SetCurrentDirectory,
|
|
|
|
* LoadLibrary, CreateProcess...
|
|
|
|
*/
|
|
|
|
static inline int xutftowcs_path(wchar_t *wcs, const char *utf)
|
|
|
|
{
|
|
|
|
return xutftowcs_path_ex(wcs, utf, MAX_PATH, -1, MAX_PATH, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Simplified file system specific variant of xutftowcsn for Windows APIs
|
|
|
|
* that support long paths via '\\?\'-prefix, assumes output buffer size is
|
|
|
|
* MAX_LONG_PATH wide chars, fails with ENAMETOOLONG if input string is too
|
|
|
|
* long. The 'core.longpaths' git-config option controls whether the path
|
|
|
|
* is only checked or expanded to a long path.
|
|
|
|
*/
|
|
|
|
static inline int xutftowcs_long_path(wchar_t *wcs, const char *utf)
|
|
|
|
{
|
|
|
|
return xutftowcs_path_ex(wcs, utf, MAX_LONG_PATH, -1, MAX_PATH,
|
|
|
|
are_long_paths_enabled());
|
|
|
|
}
|
|
|
|
|
2011-11-26 00:05:06 +04:00
|
|
|
/**
|
|
|
|
* Converts UTF-16LE encoded string to UTF-8.
|
|
|
|
*
|
|
|
|
* Maximum space requirement for the target buffer is three UTF-8 chars per
|
|
|
|
* wide char ((_wcslen(wcs) * 3) + 1).
|
|
|
|
*
|
|
|
|
* The maximum space is needed only if the entire input string consists of
|
|
|
|
* UTF-16 words in range 0x0800-0xd7ff or 0xe000-0xffff (i.e. \u0800-\uffff
|
|
|
|
* modulo surrogate pairs), as per the following table:
|
|
|
|
*
|
|
|
|
* | | UTF-16 | UTF-8 |
|
|
|
|
* Code point | UTF-16 sequence | words | bytes | ratio
|
|
|
|
* --------------+-----------------------+--------+-------+-------
|
|
|
|
* 000000-00007f | 0000-007f | 1 | 1 | 1
|
|
|
|
* 000080-0007ff | 0080-07ff | 1 | 2 | 2
|
|
|
|
* 000800-00ffff | 0800-d7ff / e000-ffff | 1 | 3 | 3
|
|
|
|
* 010000-10ffff | d800-dbff + dc00-dfff | 2 | 4 | 2
|
|
|
|
*
|
|
|
|
* Note that invalid code points > 10ffff cannot be represented in UTF-16.
|
|
|
|
*
|
|
|
|
* Parameters:
|
|
|
|
* utf: target buffer
|
|
|
|
* wcs: wide string to convert
|
|
|
|
* utflen: size of target buffer
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* length of converted string, or -1 on failure
|
|
|
|
*
|
|
|
|
* Errors:
|
|
|
|
* EINVAL: one of the input parameters is invalid (e.g. NULL)
|
|
|
|
* ERANGE: the output buffer is too small
|
|
|
|
*/
|
|
|
|
int xwcstoutf(char *utf, const wchar_t *wcs, size_t utflen);
|
|
|
|
|
2013-04-27 23:18:55 +04:00
|
|
|
/*
|
|
|
|
* A critical section used in the implementation of the spawn
|
2019-11-05 20:07:23 +03:00
|
|
|
* functions (mingw_spawnv[p]e()) and waitpid(). Initialised in
|
2013-04-27 23:18:55 +04:00
|
|
|
* the replacement main() macro below.
|
|
|
|
*/
|
|
|
|
extern CRITICAL_SECTION pinfo_cs;
|
|
|
|
|
2008-07-21 23:19:57 +04:00
|
|
|
/*
|
mingw: replace mingw_startup() hack
Git for Windows has special code to retrieve the command-line parameters
(and even the environment) in UTF-16 encoding, so that they can be
converted to UTF-8. This is necessary because Git for Windows wants to
use UTF-8 encoded strings throughout its code, and the main() function
does not get the parameters in that encoding.
To do that, we used the __wgetmainargs() function, which is not even a
Win32 API function, but provided by the MINGW "runtime" instead.
Obviously, this method would not work with any compiler other than GCC,
and in preparation for compiling with Visual C++, we would like to avoid
precisely that.
Lucky us, there is a much more elegant way: we can simply implement the
UTF-16 variant of `main()`: `wmain()`.
To make that work, we need to link with -municode. The command-line
parameters are passed to `wmain()` encoded in UTF-16, as desired, and
this method also works with GCC, and also with Visual C++ after
adjusting the MSVC linker flags to force it to use `wmain()`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20 00:05:59 +03:00
|
|
|
* Git, like most portable C applications, implements a main() function. On
|
|
|
|
* Windows, this main() function would receive parameters encoded in the
|
|
|
|
* current locale, but Git for Windows would prefer UTF-8 encoded parameters.
|
|
|
|
*
|
|
|
|
* To make that happen, we still declare main() here, and then declare and
|
|
|
|
* implement wmain() (which is the Unicode variant of main()) and compile with
|
|
|
|
* -municode. This wmain() function reencodes the parameters from UTF-16 to
|
|
|
|
* UTF-8 format, sets up a couple of other things as required on Windows, and
|
|
|
|
* then hands off to the main() function.
|
2008-07-21 23:19:57 +04:00
|
|
|
*/
|
mingw: replace mingw_startup() hack
Git for Windows has special code to retrieve the command-line parameters
(and even the environment) in UTF-16 encoding, so that they can be
converted to UTF-8. This is necessary because Git for Windows wants to
use UTF-8 encoded strings throughout its code, and the main() function
does not get the parameters in that encoding.
To do that, we used the __wgetmainargs() function, which is not even a
Win32 API function, but provided by the MINGW "runtime" instead.
Obviously, this method would not work with any compiler other than GCC,
and in preparation for compiling with Visual C++, we would like to avoid
precisely that.
Lucky us, there is a much more elegant way: we can simply implement the
UTF-16 variant of `main()`: `wmain()`.
To make that work, we need to link with -municode. The command-line
parameters are passed to `wmain()` encoded in UTF-16, as desired, and
this method also works with GCC, and also with Visual C++ after
adjusting the MSVC linker flags to force it to use `wmain()`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20 00:05:59 +03:00
|
|
|
int wmain(int argc, const wchar_t **w_argv);
|
|
|
|
int main(int argc, const char **argv);
|
2009-05-31 20:15:22 +04:00
|
|
|
|
2020-02-14 00:49:53 +03:00
|
|
|
/*
|
|
|
|
* For debugging: if a problem occurs, say, in a Git process that is spawned
|
|
|
|
* from another Git process which in turn is spawned from yet another Git
|
|
|
|
* process, it can be quite daunting to figure out what is going on.
|
|
|
|
*
|
|
|
|
* Call this function to open a new MinTTY (this assumes you are in Git for
|
|
|
|
* Windows' SDK) with a GDB that attaches to the current process right away.
|
|
|
|
*/
|
2020-10-07 11:31:59 +03:00
|
|
|
void open_in_gdb(void);
|
2020-02-14 00:49:53 +03:00
|
|
|
|
2010-01-15 23:12:20 +03:00
|
|
|
/*
|
|
|
|
* Used by Pthread API implementation for Windows
|
|
|
|
*/
|
2019-09-04 14:09:48 +03:00
|
|
|
int err_win_to_posix(DWORD winerr);
|
2018-04-23 16:30:18 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check current process is inside Windows Container.
|
|
|
|
*/
|
|
|
|
int is_inside_windows_container(void);
|