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>
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>
Commit 4a36897af3 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>
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>
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>
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>
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>
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.
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
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'.
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.
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.
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>
- 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>
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>
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>
Commit 35998fc2fa 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>
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>
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>
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>
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>
* 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>
* Rename DEV_TCP_MAJOR to DEV_SOCK_MAJOR
* Drop FH_TCP, FH_UDP, FH_ICMP in favor of single FH_INET
* Drop FH_UNIX, FH_STREAM, FH_DGRAM in favor of single FH_LOCAL
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far we had two functions checking the content of a reparse point,
readdir_check_reparse_point in fhandler_disk_file.cc for the sake of
readdir, and symlink_info::check_reparse_point for the sake of
generic path checking.
* Rename check_reparse_point_target helper to check_reparse_point_string
and convert to static function.
* Create new check_reparse_point_target helper containing the core
reparse point checking code
* Just call check_reparse_point_target from readdir_check_reparse_point
and symlink_info::check_reparse_point and only perform the unique
task in those functions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Add new SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag to
CreateSymbolicLinkW call when running on W10 1703 or later.
Don't do that on older versions to avoid ERROR_INVALID_PARAMETER.
Preliminary, needs testing. There's an off-chance that the
flag results in the same ERROR_INVALID_PARAMETER on 1703 if the
developer settings are not enabled.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
There are certain, very obscure scenarios, which render the Windows
CWD handle inaccessible for reopening. An easy one is, the handle can
be NULL if the permissions of the CWD changed under the parent processes
feet.
Originally we just set errno and returned, but in case of init at
process startup that left the "posix" member NULL and subsequent
calls to getcwd failed with EFAULT.
We now check for a NULL handle and change the reopen approach
accordingly. If that doesn't work, try to duplicate the handle instead.
If duplicating fails, too, we set the dir handle to NULL and carry on.
This will at least set posix to some valid path and subsequent getcwd
calls won't fail. A NULL dir handle is ok, because we already do this
for virtual paths.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
A *very* recent Windows build adds more code to the preamble of
RtlGetCurrentDirectory_U() so that the previous heuristic failed to find
the call to the locking routine.
This only affects the 64-bit version of ntdll, where the 0xe8 byte is
now found at offset 40, not the 32-bit version. However, let's just
double the area we search for said byte for good measure.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
NtOpenFile/NtCreateFile on non-existent paths on network drives has a
bug. Assuming a path Z:\dir\file. Further assuming that Z:\dir does
not exist.
The first NtOpenFile("Z:\dir\file") correctly returns
STATUS_OBJECT_PATH_NOT_FOUND. Subsequent calls incorrectly
return STATUS_OBJECT_NAME_NOT_FOUND.
This appears to be some kind of caching behaviour. Waiting a while
before repeating the call correctly returns STATUS_OBJECT_PATH_NOT_FOUND
again.
This patch works around the observed misbehaviour.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far, when converting from POSIX to Windows notation, cygwin_conv_path
fails to check for .exe suffix, so /path/foo did not return /path/foo.exe
even if this file exists.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The original code only skipped the "./", but missed to test if more
trailing slashes are present. This in turn leads to invalid conversion.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Corinna Vinschen
Ken Brown
Arseniy Lartsev
Joe_Lowe
Johannes Schindelin