summaryrefslogtreecommitdiff
path: root/compat/cygwin.c
AgeCommit message (Collapse)AuthorFilesLines
2018-12-26git clone <url> C:\cygwin\home\USER\repo' is working (again)Libravatar Torsten Bögershausen1-19/+0
A regression for cygwin users was introduced with commit 05b458c, "real_path: resolve symlinks by hand". In the the commit message we read: The current implementation of real_path uses chdir() in order to resolve symlinks. Unfortunately this isn't thread-safe as chdir() affects a process as a whole... The old (and non-thread-save) OS calls chdir()/pwd() had been replaced by a string operation. The cygwin layer "knows" that "C:\cygwin" is an absolute path, but the new string operation does not. "git clone <url> C:\cygwin\home\USER\repo" fails like this: fatal: Invalid path '/home/USER/repo/C:\cygwin\home\USER\repo' The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix() is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin in the same way as it is done in 'Git for Windows' in compat/mingw.[ch] Extract the needed code into compat/win32/path-utils.[ch] and use it for cygwin as well. Reported-by: Steven Penny <svnpenn@gmail.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-05cygwin: allow pushing to UNC pathsLibravatar Torsten Bögershausen1-0/+19
cygwin can use an UNC path like //server/share/repo $ cd //server/share/dir $ mkdir test $ cd test $ git init --bare However, when we try to push from a local Git repository to this repo, there is a problem: Git converts the leading "//" into a single "/". As cygwin handles an UNC path so well, Git can support them better: - Introduce cygwin_offset_1st_component() which keeps the leading "//", similar to what Git for Windows does. - Move CYGWIN out of the POSIX in the tests for path normalization in t0060 Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18cygwin: Remove the Win32 l/stat() implementationLibravatar Ramsay Jones1-157/+0
Commit adbc0b6b ("cygwin: Use native Win32 API for stat", 30-09-2008) added a Win32 specific implementation of the stat functions. In order to handle absolute paths, cygwin mount points and symbolic links, this implementation may fall back on the standard cygwin l/stat() functions. Also, the choice of cygwin or Win32 functions is made lazily (by the first call(s) to l/stat) based on the state of some config variables. Unfortunately, this "schizophrenic stat" implementation has been the source of many problems ever since. For example, see commits 7faee6b8, 79748439, 452993c2, 085479e7, b8a97333, 924aaf3e, 05bab3ea and 0117c2f0. In order to avoid further problems, such as the issue raised by the new reference handling API, remove the Win32 l/stat() implementation. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08cygwin: Remove the CYGWIN_V15_WIN32API build variableLibravatar Ramsay Jones1-5/+0
Commit 380a4d92 ("Update cygwin.c for new mingw-64 win32 api headers", 11-11-2012) solved an header include order problem on cygwin 1.7 when using the new mingw-64 WIN32 API headers. The solution involved using a new build variable (V15_MINGW_HEADERS) to conditionally compile the cygwin.c source file to use an include order appropriate for the old and new header files. (The build variable was later renamed in commit 9fca6cff to CYGWIN_V15_WIN32API). The include order used for cygwin 1.7 includes the "win32.h" header before "../git-compat-util.h". This order was problematic on cygwin 1.5, since it lead to the WIN32 symbol being defined along with the inclusion of some WIN32 API headers (e.g. <winsock2.h>) which cause compilation errors. The header include order problem on cygwin 1.5 has since been fixed (see commit "mingw: rename WIN32 cpp macro to GIT_WINDOWS_NATIVE"), so we can now remove the conditional compilation along with the associated CYGWIN_V15_WIN32API build variable. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25Make core.sharedRepository work under cygwin 1.7Libravatar Torsten Bögershausen1-0/+13
When core.sharedRepository is used, set_shared_perm() in path.c needs lstat() to return the correct POSIX permissions. The default for cygwin is core.ignoreCygwinFSTricks = false, which means that the fast implementation in do_stat() is used instead of lstat(). lstat() under cygwin uses the Windows security model to implement POSIX-like permissions. The user, group or everyone bits can be set individually. do_stat() simplifes the file permission bits, and may return a wrong value. The read-only attribute of a file is used to calculate the permissions, resulting in either rw-r--r-- or r--r--r-- One effect of the simplified do_stat() is that t1301 fails. Add a function cygwin_get_st_mode_bits() which returns the POSIX permissions. When not compiling for cygwin, true_mode_bits() in path.c is used. Side note: t1301 passes under cygwin 1.5. The "user write" bit is synchronized with the "read only" attribute of a file: $ chmod 444 x $ attrib x A R C:\temp\pt\x cygwin 1.7 would show A C:\temp\pt\x Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-18USE CGYWIN_V15_WIN32API as macro to select api for cygwinLibravatar Mark Levedahl1-1/+1
The previous macro was confusing to some, and did not include "cygwin" in its name. The updated name more clearly expresses a choice of the win32api implementation that shipped with version 1.5 of cygwin. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-12Update cygwin.c for new mingw-64 win32 api headersLibravatar Mark Levedahl1-0/+7
The cygwin project recently switched to a new implementation of the windows api, now using header files from the mingw-64 project. These new header files are incompatible with the way cygwin.c included the old headers: cygwin.c can be compiled using the new or the older (mingw) headers, but different files must be included in different order for each to work. The new headers are in use only for the current release series (based upon the v1.7.x dll version). The previous release series using the v1.5 dll is kept available but unmaintained for use on older versions of Windows. So, patch cygwin.c to use the new include ordering only if the dll version is 1.7 or higher. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2011-07-13Merge branch 'jc/maint-cygwin-trust-executable-bit-default'Libravatar Junio C Hamano1-1/+1
* jc/maint-cygwin-trust-executable-bit-default: cygwin: trust executable bit by default
2011-06-20cygwin: trust executable bit by defaultLibravatar Junio C Hamano1-1/+1
Earlier 7974843 (compat/cygwin.c: make runtime detection of lstat/stat lessor impact, 2008-10-23) fixed the low-level "do we use cygwin specific hacks for stat/lstat?" logic not to call into git_default_config() from random codepaths that are typically very late in the program, to prevent the call from potentially overwriting other variables that are initialized from the configuration. However, it forgot that on Cygwin, trust-executable-bit should default to true. Noticed by J6t, confirmed by Ramsay Jones, and the brown paper bag is on Gitster's head. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-16t1301-*.sh: Fix the 'forced modes' test on cygwinLibravatar Ramsay Jones1-2/+1
The 'forced modes' test fails on cygwin because the post-update hook loses it's executable bit when copied from the templates directory by git-init. The template loses it's executable bit because the lstat() function resolves to the "native Win32 API" implementation. This call to lstat() happens after git-init has set the "git_dir" (so has_git_dir() returns true), but before the configuration has been fully initialised. At this point git_config() does not find any config files to parse and returns 0. Unfortunately, the code used to determine the cygwin l/stat() function bindings did not check the return from git_config() and assumed that the config was complete and accessible once "git_dir" was set. In order to fix the test, we simply change the binding code to test the return value from git_config(), to ensure that it actually had config values to read, before determining the requested binding. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22Fix more typos/spelling in commentsLibravatar Michael J Gruber1-1/+1
A few more fixes on top of the automatic spell checker generated ones. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22Fix typos / spelling in commentsLibravatar Mike Ralphson1-1/+1
Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-28compat/cygwin.c: make runtime detection of lstat/stat lessor impactLibravatar Junio C Hamano1-7/+13
The original patch that lead to an earlier commit adbc0b6 (cygwin: Use native Win32 API for stat, 2008-09-30) did not call git_default_config() and it was a good thing. The lazy config reading when lstat/stat is called for the first time to find out if core.filemode is set can happen anytime in the calling program. If it happens after the calling program parsed the configuration file to prime its default parameter settings and processed its command line parameters to tweak them, this will overwrite the values set by the program with the values read from the config file. This essentially reverts the code to the version as submitted by Mark, with a bit more comments to clarify why we do not fall back on the default configuration parser from git_cygwin_config(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-13compat/cygwin.c - Use cygwin's stat if core.filemode == trueLibravatar Mark Levedahl1-4/+14
Cygwin's POSIX emulation allows use of core.filemode true, unlike native Window's implementation of stat / lstat, and Cygwin/git users who have configured core.filemode true in various repositories will be very unpleasantly surprised to find that git is no longer honoring that option. So, this patch forces use of Cygwin's stat functions if core.filemode is set true, regardless of any other considerations. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-30cygwin: Use native Win32 API for statLibravatar Dmitry Potapov1-0/+127
lstat/stat functions in Cygwin are very slow, because they try to emulate some *nix things that Git does not actually need. This patch adds Win32 specific implementation of these functions for Cygwin. This implementation handles most situation directly but in some rare cases it falls back on the implementation provided for Cygwin. This is necessary for two reasons: - Cygwin has its own file hierarchy, so absolute paths used in Cygwin is not suitable to be used Win32 API. cygwin_conv_to_win32_path can not be used because it automatically dereference Cygwin symbol links, also it causes extra syscall. Fortunately Git rarely use absolute paths, so we always use Cygwin implementation for absolute paths. - Support of symbol links. Cygwin stores symbol links as ordinary using one of two possible formats. Therefore, the fast implementation falls back to Cygwin functions if it detects potential use of symbol links. The speed of this implementation should be the same as mingw_lstat for common cases, but it is considerable slower when the specified file name does not exist. Despite all efforts to make the fast implementation as robust as possible, it may not work well for some very rare situations. I am aware only one situation: use Cygwin mount to bind unrelated paths inside repository together. Therefore, the core.ignoreCygwinFSTricks configuration option is provided, which controls whether native or Cygwin version of stat is used. Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>