summaryrefslogtreecommitdiffstats
path: root/winsup/cygwin/path.cc
Commit message (Collapse)AuthorAgeFilesLines
* Fix broken handling of drive relative paths.Kaz Kylheku2024-01-021-7/+11
| | | | | | * winsup/cygwin/path.cc (normalize_win32_path): Fix bungled logic for replacing a relative drive reference with the working directory from that drive. We were wrongly copying an extra drive letter character.
* Implement drive-relative paths and per-drive working dir.Kaz Kylheku2021-07-261-1/+40
| | | | | | | | | | | | | | | | | | | | | | * winsup/cygwin/path.cc (normalize_win32_path): When a drive-relative path is normalized, look up the remembered working directory of that drive in the environment. A drive-relative path is, for example, "C:file.txt". Or just "C:", with no component. If there is no path for the drive in the environment, then the root directory is used, and the "C:" part thus becomes "C:\", causing the path to refer to "C:\file.txt". Otherwise the path is inserted, with a backslash, like "C:\users\bob\file.txt". The Windows convention for storing these per-drive paths in the environment is to use environment variables based on drive letters. For instance the path for the C drive is stored in the environment variable "!C:" (bang, letter, colon). The path includes the C:\ prefix. (cwdstuff::override_win32_cwd): Add the behavior of associating the current working directory with its drive (if it is a current working directory based on a drive). For instance if the overriding cwd is "C:\Users", then the "C:\Users" path is stored into the "!C:" environment variable.
* First steps toward native path handling.Kaz Kylheku2021-07-261-29/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - /proc and /dev are are still available, accessed as proc:/ and dev:/ - All other paths are native, and do not "see" virtual Cygwin items; /cygdrive is just C:\cygdrive (if the current drive is C). - chdir() to a virtual directory like dev:/ or proc:/ results in errno EOPNOTSUPP. * winsup/cygwin/mount.cc (mount_info::conv_to_win32_path): Takes new bool argument, hide_cygwin_virtuals. If true all that the function does is "backslashify" the path. (mount_info::add_item): Special hack inserted here so that we can create the virtual root directory which holds dev and proc and whatnot, and is passed here as "/". We cannot let this go through normalize_posix_path any more because it will turn to C:\. * winsup/cygwin/mount.h (mount_info::conv_to_win32_path): Declaration updated. * winsup/cygwin/path.cc (is_posix_space): New static function: tests for paths in special spaces, currently "dev:/" and "proc:/". Used by normalize_posix_path. (normalize_posix_path): Any path that doesn't satisfy the is_posix_space test is treated as Win32. Since the bulk of the code is now only used for these spaces, the relative path handling is not required and a the corresponding block of code is removed. Paths satisfying is_posix_space are transformed. I.e. the underlying path resolution machine in the path_conv class still recognizes /proc and /dev. It's just that these will not occur, because normalize_posix_path will convert them to references with drive names. (path_conv::check): Pass the is_msdos flag down to mount_info::conv_to_win32_path as the new argument. Thus if normalize_posix_path indicates a native path, this function will hide the virtual spaces. Also, we add MOUNT_NOPOSIX and MOUNT_NOACL to the object's mount_flags. This is used in chdir. (normalize_win32_path): A small piece of logic works against our plan here: it checks for the leading forward slash on the path, and prevents such paths from being converted to Win32 paths with a drive reference. We eliminate this test, and treat paths unconditionally. (chdir): Here, if the path is not native, we return EOPNOTSUPP. Thus it is impossible to chdir into Cygwin virtual directories like /dev (now referenced as dev:/). They can be listed but not turned into the current directory. Eventually we want chdir to actually set the Win32 current directory of the process; that can't work for virtual dirs. * winsup/cygwin/path.h (path_conv::is_native): New inline accessor which tests for the MOUNT_NOPOSIX flag.
* Cygwin: Treat Windows Store's "app execution aliases" as symbolic linksJohannes Schindelin2021-03-231-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the Windows Store version of Python is installed, so-called "app execution aliases" are put into the `PATH`. These are reparse points under the hood, with an undocumented format. We do know a bit about this format, though, as per the excellent analysis: https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html The first 4 bytes is the reparse tag, in this case it's 0x8000001B which is documented in the Windows SDK as IO_REPARSE_TAG_APPEXECLINK. Unfortunately there doesn't seem to be a corresponding structure, but with a bit of reverse engineering we can work out the format is as follows: Version: <4 byte integer> Package ID: <NUL Terminated Unicode String> Entry Point: <NUL Terminated Unicode String> Executable: <NUL Terminated Unicode String> Application Type: <NUL Terminated Unicode String> Let's treat them as symbolic links. For example, in this developer's setup, this will result in the following nice output: $ cd $LOCALAPPDATA/Microsoft/WindowsApps/ $ ls -l python3.exe lrwxrwxrwx 1 me 4096 105 Aug 23 2020 python3.exe -> '/c/Program Files/WindowsApps/PythonSoftwareFoundation.Python.3.7_3.7.2544.0_x64__qbz5n2kfra8p0/python.exe' Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* Cygwin: recognize native Windows AF_UNIX sockets as reparse pointsKen Brown2021-02-011-0/+4
| | | | | | | | | | | | | Allow check_reparse_point_target to recognize reparse points with reparse tag IO_REPARSE_TAG_AF_UNIX. These are used in recent versions of Windows 10 to represent AF_UNIX sockets. check_reparse_point_target now returns PATH_REP on files of this type, so that they are treated as known reparse points (but not as sockets). This allows tools like 'rm', 'ls', etc. to operate on these files. Addresses: https://cygwin.com/pipermail/cygwin/2020-September/246362.html https://cygwin.com/pipermail/cygwin/2021-January/247666.html
* Cygwin: normalize_posix_path: fix error handling when .. is encounteredKen Brown2021-01-221-1/+3
| | | | | | | | | | When .. is in the source path and the path prefix exists but is not a directory, return ENOTDIR instead of ENOENT. This fixes a POSIX compliance issue for realpath(3): https://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html Addresses: https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00214.html
* Cygwin: add flag to indicate reparse points unknown to WinAPICorinna Vinschen2020-12-021-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://cygwin.com/pipermail/cygwin/2020-December/246938.html reports a problem where, when adding a Cygwin default symlink to $PATH since Cygwin 3.1.5, $PATH handling appears to be broken. 3.1.5 switched to WSL symlinks as Cygwin default symlinks. A piece of code in path handling skips resolving reparse points if they are the last component in the path. Thus a reparse point in $PATH is not resolved but converted to Windows path syntax verbatim. If you do this with a WSL symlink, certain WinAPI functions fail. The underlying $PATH handling fails to recognize the reparse point in $PATH and returns with STATUS_IO_REPARSE_TAG_NOT_HANDLED. As a result, the calling WinAPI function fails, most prominently so CreateProcess. Fix this problem by adding a PATH_REP_NOAPI bit to path_types and a matching method path_conv::is_winapi_reparse_point(). Right now this flag is set for WSL symlinks and Cygwin AF_UNIX sockets (new type implemented as reparse points). The aforementioned code skipping repare point path resolution calls is_winapi_reparse_point() rather than is_known_reparse_point(), so now path resolution is only skipped for reparse points known to WinAPI. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: Fix access to block devices below /proc/sys.Christian Franke2020-11-301-10/+19
| | | | | | | | Use fhandler_dev_floppy instead of fhandler_procsys for such devices. The read()/write() functions from fhandler_procsys do not ensure sector aligned transfers and lseek() fails always. Signed-off-by: Christian Franke <franke@computer.org>
* Cygwin: always recognize AF_UNIX sockets as reparse pointsKen Brown2020-10-041-4/+6
| | | | | | | | | | | | | | | If __WITH_AF_UNIX is defined when Cygwin is built, then a named AF_UNIX socket is represented by a reparse point with a Cygwin-specific tag and GUID. Make such files recognizable as reparse points (but not as sockets) even if __WITH_AF_UNIX is not defined. That way utilities such as 'ls' and 'rm' still behave reasonably. This requires two changes: - Define the GUID __cygwin_socket_guid unconditionally. - Make check_reparse_point_target return PATH_REP on a reparse point of this type if __WITH_AF_UNIX is not defined.
* Cygwin: fix handling of known reparse points that are not symlinksKen Brown2020-10-041-5/+12
| | | | | | | | | | | | | | | | | | Commit aa467e6e, "Cygwin: add AF_UNIX reparse points to path handling", changed check_reparse_point_target so that it could return a positive value on a known reparse point that is not a symlink. But some of the code in check_reparse_point that handles this positive return value was executed unconditionally, when it should have been executed only for symlinks. As a result, posixify could be called on a buffer containing garbage, and check_reparse_point could erroneously return a positive value on a non-symlink. This is now fixed so that posixify is only called if the reparse point is a symlink, and check_reparse_point returns 0 if the reparse point is not a symlink. Also fix symlink_info::check to handle this last case, in which check_reparse_point returns 0 on a known reparse point.
* Cygwin: check_reparse_point_target: update commentKen Brown2020-09-261-2/+3
| | | | | | Commit aa467e6e, "Cygwin: add AF_UNIX reparse points to path handling", changed the return values of check_reparse_point_target. Update the comment accordingly.
* Cygwin: path_conv::check: handle error from fhandler_process::existsKen Brown2020-09-081-0/+9
| | | | | | | fhandler_process::exists is called when we are checking a path starting with "/proc/<pid>/fd". If it returns virt_none and sets an errno, there is no need for further checking. Just set 'error' and return.
* Cygwin: cwdstuff::get: clean up debug_printf outputKen Brown2020-08-231-0/+2
| | | | | | Set errno = 0 at the beginning so that the debug_printf call at the end doesn't report a nonzero errno left over from some other function call.
* Cygwin: Add 'fallthrough' pseudo keyword for switch/case useCorinna Vinschen2020-08-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch has been inspired by the Linux kernel patch 294f69e662d1 compiler_attributes.h: Add 'fallthrough' pseudo keyword for switch/case use written by Joe Perches <joe AT perches DOT com> based on an idea from Dan Carpenter <dan DOT carpenter AT oracle DOT com>. The following text is from the original log message: Reserve the pseudo keyword 'fallthrough' for the ability to convert the various case block /* fallthrough */ style comments to appear to be an actual reserved word with the same gcc case block missing fallthrough warning capability. All switch/case blocks now should end in one of: break; fallthrough; goto <label>; return [expression]; continue; In C mode, GCC supports the __fallthrough__ attribute since 7.1, the same time the warning and the comment parsing were introduced. Cygwin-only: add an explicit -Wimplicit-fallthrough=5 to the build flags.
* Cygwin: symlinks: fix WSL symlink creation if cygdrive prefix is /Corinna Vinschen2020-04-211-4/+6
| | | | | | | | | | | | | | | | | | If the cygdrive prefix is /, then the following happens right now: $ ln -s /tmp/foo . $ ls -l foo lrwxrwxrwx 1 user group 12 Apr 15 23:44 foo -> /mnt/tmp/foo Fix this by skipping cygdrive prefix conversion to WSL drive prefix "/mnt", if the cygdrive prefix is just "/". There's no satisfying way to do the right thing all the time in this case anyway. For a description and the alternatives, see https://cygwin.com/pipermail/cygwin-developers/2020-April/011859.html Also, fix a typo in a comment. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: symlinks: Allow traversing WSL symlinksCorinna Vinschen2020-04-051-0/+6
| | | | | | | | | | | | Unfortunately Windows doesn't understand WSL symlinks, despite being a really easy job. NT functions trying to access paths traversing WSL symlinks return the status code STATUS_IO_REPARSE_TAG_NOT_HANDLED. Handle this status code same as STATUS_OBJECT_PATH_NOT_FOUND in symlink_info::check to align behaviour to traversing paths with other non-NTFS type symlinks. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: symlinks: create WSL symlinks on supporting filesystemsCorinna Vinschen2020-04-031-24/+103
| | | | | | | | | WSL symlinks are reparse points containing a POSIX path in UTF-8. On filesystems supporting reparse points, use this symlink type. On other filesystems, or in case of error, fall back to the good old plain SYSTEM file. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: symlinks: fix WSL symlinks pointing to /mntCorinna Vinschen2020-04-021-15/+35
| | | | | | | | | | Commit 4a36897af392 allowed to convert /mnt/<drive> path prefixes to Cygwin cygdrive prefixes on the fly. However, the patch neglected WSL symlinks pointing to the /mnt directory. Rearrange path conversion so /mnt is converted to the cygdrive prefix path itself. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: symlinks: support WSL symlinksCorinna Vinschen2020-03-271-0/+73
| | | | | | | | Treat WSL symlinks just like other symlinks. Convert absolute paths pointing to Windows drives via /mnt/<driveletter> to Windows-style paths <driveletter>: Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: fix formatting: collapse whitespace-only linesCorinna Vinschen2020-03-111-1/+1
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: fix formatting: drop spaces leading tabsCorinna Vinschen2020-03-111-6/+6
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: remove CYGWIN=dos_file_warning optionCorinna Vinschen2020-01-281-32/+4
| | | | | | | This option has been disabled long ago and nobody missed it. Removing drops a bit of unneeded code Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: symlink/mknod: fix ACL handlingCorinna Vinschen2020-01-281-35/+34
| | | | | | | | | | | | | | mknod32 actually creates a path_conv, just to call mknod_worker with a win32 path. This doesn't only require to create path_conv twice, it also breaks permissions on filesystems supporting ACLs. Fix this by passing the path_conv created in the caller down to symlink_worker. Also, while at it, simplify the handling of trailing slashes and move it out of symlink_worker. Especially use the new PC_SYM_NOFOLLOW_DIR flag to avoid fiddeling with creating a new path copy without the trailing slash. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: path_conv: add PC_SYM_NOFOLLOW_DIR flagCorinna Vinschen2020-01-281-7/+20
| | | | | | | | | | | | | Usually a trailing slash requires to follow an existing symlink, even with PC_SYM_NOFOLLOW. The reason is that "foo/" is equivalent to "foo/." so the symlink is in fact not the last path component, "." is. This is default for almost all scenarios. PC_SYM_NOFOLLOW_DIR now allows the caller to request not to follow the symlink even if a trailing slash is given. This can be used in callers to perform certain functions Linux-compatible. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: normalize_win32_path: allow drive without trailing backslashKen Brown2020-01-171-1/+1
| | | | | | | | | | | | | | Commit 283cb372, "Cygwin: normalize_win32_path: improve error checking", required a prefix '\\?\' or '\??\' in the source path to be followed by 'UNC\' or 'X:\', where X is a drive letter. That was too restrictive, since it disallowed the paths '\\?\X: and '\??\X:'. This caused problems when a user tried to use the root of a drive as the Cygwin installation root, as reported here: https://cygwin.com/ml/cygwin/2020-01/msg00111.html Modify the requirement so that '\??\X:' and '\\?\X:' are now allowed as source paths, without a trailing backslash.
* Fixed crash on wine by adding NULL check after memchrArseniy Lartsev2020-01-131-0/+2
| | | | | This is not a joke, there are vendors out there who build software for cygwin only. Besides, this NULL check is good to have anyway.
* Cygwin: symlink_info::check: avoid assertion failureKen Brown2019-12-091-1/+2
| | | | | | | | | | | On certain error conditions there is a code snippet that checks whether the last component of the path has a trailing dot or space or a leading space. Skip this check if the last component is empty, i.e., if the path ends with a backslash. This avoids an assertion failure if the trailing backslash is the only backslash in the path, as is the case for a DOS drive 'X:\'. Addresses: https://cygwin.com/ml/cygwin/2019-12/msg00016.html
* Cygwin: normalize_win32_path: improve error checkingKen Brown2019-09-261-3/+6
| | | | | | | | | | | | | | If the source path starts with the Win32 long path prefix '\\?\' or the NT object directory prefix '\??\', require the prefix to be followed by 'UNC\' or '<drive letter>:\'. Otherwise return EINVAL. This fixes the assertion failure in symlink_info::check that was reported here: https://cygwin.com/ml/cygwin/2019-09/msg00228.html That assertion failure was caused by normalize_win32_path returning a path with no backslashes when the source path was '\\?\DRIVE'.
* Cygwin: remove old cruft from path_conv::checkKen Brown2019-09-211-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to commit b0717aae, path_conv::check had the following code: if (strncmp (path, "\\\\.\\", 4)) { /* Windows ignores trailing dots and spaces in the last path component, and ignores exactly one trailing dot in inner path components. */ char *tail = NULL; [...] if (!tail || tail == path) /* nothing */; else if (tail[-1] != '\\') { *tail = '\0'; [...] } Commit b0717aae0 intended to disable this code, but it inadvertently disabled only part of it. In particular, the declaration of the local tail variable was in the disabled code, but the following remained: if (!tail || tail == path) /* nothing */; else if (tail[-1] != '\\') { *tail = '\0'; [...] } [A later commit removed the disabled code.] The tail variable here points into a string different from path, causing that string to be truncated under some circumstances. See https://cygwin.com/ml/cygwin/2019-09/msg00001.html for more details. This commit fixes the problem by removing the leftover code that was intended to be removed in b0717aae.
* Cygwin: remove path_conv::is_auto_device()Ken Brown2019-07-221-1/+1
| | | | | | | It is used only once, and the name is supposed to suggest "device that is not based on the filesystem". This intended meaning is clearer if we just replace is_auto_device() by its definition at the place where it's used.
* Cygwin: avoid GCC 8.3 errors with -Werror=class-memaccessKen Brown2019-07-161-2/+2
|
* Cygwin: path_conv: add PATH_RESOLVE_PROCFD path_types flagCorinna Vinschen2019-01-061-1/+4
| | | | | | | | | | | path_conv now sets the PATH_RESOLVE_PROCFD flag in path_flags if the PC_SYM_NOFOLLOW_PROCFD pathconv_arg flag has been set on input *and* the file is actually a proc fd symlink. Add matching path_conv::follow_fd_symlink method for checking and use it in open(2). Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: path_conv: decouple path_types from mount typesCorinna Vinschen2019-01-061-34/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Remove another unfortunate amalgamation: Mount flags (MOUNT_xxx) are converted to path_types (PATH_xxx) and mixed with non-mount path_types flags in the same storage, leading to a tangled, pell-mell usage of mount flags and path flags in path_conv and symlink_info. - There's also the case of PC_NONULLEMPTY. It's used in exactly one place with a path_conv constructor only used in this single place, just to override the automatic PC_NULLEMPTY addition when calling the other path_conv constructors. Crazily, PC_NONULLEMPTY is a define, no path_types flag, despite its name. - It doesn't help that the binary flag exists as mount and path flag, while the text flag only exists as path flag. This leads to mount code using path flags to set text/binary. Very confusing is the fact that a text mount/path flag is not actually required; the mount code sets the text flag on non binary mounts anyway, so there are only two states. However, to puzzle people a bit more, path_conv::binary wrongly implies there's a third, non-binary/non-text state. Clean up this mess: - Store path flags separately from mount flags in path_conv and symlink_info classes and change all checks and testing inline methods accordingly. - Make PC_NONULLEMPTY a simple path_types flag and drop the redundant path_check constructor. - Clean up the definition of pathconv_arg, path_types, and mount flags. Use _BIT expression, newly define in cygwin/bits.h. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: path_conv: decouple pathconv_flags from path_typesCorinna Vinschen2019-01-061-8/+11
| | | | | | | | | | | | | | | There's an unfortunate amalgamation of caller-provided pathconv_arg flags with path_types flags which in turn are mostly mount flags. This leads to a confusion of flag values in sylink_info::pflags and, in turn, in path_conv::path_flags. This patch decouples pathconv_flags from the other flags by making sure that a pathconv_flag is never copied into a variable used for path_types flags. Also, remove PATH_NO_ACCESS_CHECK since it's not necessary. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: implement /proc/PID/fd/DESCRIPTOR reopening by handleCorinna Vinschen2019-01-061-0/+4
| | | | | | | | | | | | | Allows expressions along the lines of `cat /proc/self/fd/0 <<EOF'. The problem here is that the temporary file used for the here script has already been deleted by the shell. Opening by filename, as implemented so far, doesn't work because the file has been moved to the bin. Allow reopening files by handle the same way from another process as long as we have sufficient permissions on the foreign process. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: path_conv: add serialization/deserialization facilityCorinna Vinschen2019-01-061-0/+64
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: introduce virt_fdsymlink to simplify /proc/PID/fd symlink handlingCorinna Vinschen2019-01-051-1/+3
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: return correct FH_PROCESSFD for files under /proc/PID/fd subdirCorinna Vinschen2019-01-051-1/+1
| | | | | | This allows easier handling of fd symlinks. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: path_conv: nobody cares if a path had symlinks after the factCorinna Vinschen2019-01-051-5/+0
| | | | | | | remove set_has_symlinks/has_symlinks/PATH_HAS_SYMLINKS. Nobody's asking for this information. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: fix Win32 path ".." backtrackingCorinna Vinschen2018-09-011-5/+16
| | | | | | | | | | | | | Commit 35998fc2fa6cbb7d761f6d88346246bd3627552b fixed the buffer underun in win32 path normalization, but introduced a new bug: A wrong assumption led to the inability to backtrack the path outside of the current working directory in case of relative paths. This patch fixes this problem, together with a minor problem if the CWD is on a network share: The result erroneously started with tripple backslash if the src path starts with a single backslash. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: Treat PROCESSOR_ARCHITECTURE_INTEL as running under WOW64 on ARM64Corinna Vinschen2018-07-121-9/+24
| | | | | | | | | | Bug in current ARM64 WOW64: GetNativeSystemInfo returns PROCESSOR_ARCHITECTURE_INTEL rather than PROCESSOR_ARCHITECTURE_ARM64. Provide for this. Make code better readable. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: Don't print FAST_CWD warning in WOW64 on ARM64 systemsCorinna Vinschen2018-07-101-1/+15
| | | | | | No way to test this, yet. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: fix a race in the FAST_CWD fallback codeCorinna Vinschen2018-07-101-22/+17
| | | | | | | | | | Guard the entire operation with the FastPebLock critical section used by RtlSetCurrentDirectory_U as well, thus eliminating the race between concurrent chdir/fchdir/SetCurrentDirectory calls. Streamline comment explaining the fallback method. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: Allow to build without experimental AF_UNIX code by defaultCorinna Vinschen2018-06-261-0/+6
| | | | | | Introduce __WITH_AF_UNIX preprocessor flag to enable the new code Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: normalize_win32_path: Avoid buffer underrunsCorinna Vinschen2018-05-291-8/+25
| | | | | | | | | | | | | | | | Thanks to Ken Harris <Ken.Harris@mathworks.com> for the diagnosis. When backing up tail to handle a "..", the code only checked that it didn't underrun the destination buffer while removing path components. It did *not* take into account that the first backslash in the path had to be kept intact. Example path to trigger the problem: "C:\A..\..\..\B' Fix this by moving the dst pointer to the first backslash so subsequent tests cannot underrun this position. Also make sure that we always *have* a backslash. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: TEST only: Add a buffer underrun assertion to symlink_info::checkCorinna Vinschen2018-05-291-1/+2
| | | | | | | | | Thanks to Ken Harris <Ken.Harris@mathworks.com> for the diagnosis which led to a buffer underrun in this loop. Revert before release. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: drop CYGWIN_SOCKET_UUID, define CYGWIN_SOCKET_GUID as GUID pointerCorinna Vinschen2018-03-021-4/+1
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: add AF_UNIX reparse points to path handlingCorinna Vinschen2018-03-011-7/+18
| | | | | | | | | | * check_reparse_point_target returns a path flag mask, rather than just 1. Return PATH_SYMLINK | PATH_REP for symlinks and directory mount points, PATH_SOCKET | PATH_REP for AF_UNIX sockets. * Define Cygwin AF_UNIX socket reparse tag and GUID in ntdll.h. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: path.cc: clean up includesCorinna Vinschen2018-03-011-12/+4
| | | | Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* Cygwin: path_conv: rename is_rep_symlink to is_known_reparse_pointCorinna Vinschen2018-03-011-1/+1
| | | | | | | ...in preparation of reusing this flag for other types of reparse points, not only symlinks. Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-15 16:28:38 +0000