Renaming files returns STATUS_INVALID_PARAMETE on a bind mounted file system
in hyper-v container with FILE_RENAME_POSIX_SEMANTICS.
Disable the use_posix_semantics flag and retry.
Signed-off-by: Yoshinao Muramatsu <ysno@ac.auone-net.jp>
Deleting files returns STATUS_INVALID_PARAMETE on a bind mounted file system
in hyper-v container with FILE_DISPOSITION_POSIX_SEMANTICS.
Therefore fall back to default method.
This code is suggested by Johannes Schindelin on github
and I change it more simple.
Signed-off-by: Yoshinao Muramatsu <ysno@ac.auone-net.jp>
If a host NTFS is mapped into a Hyper-V isolated container, the
OPEN_BY_FILE_ID filesystem flag is missing, just as if that NTFS
is a remote drive. However, NtQueryVolumeInformationFile claims
the drive is a local drive.
We can use this fact to learn that the process is running under
Hyper-V, and that the Hyper-V isolated process can't use rename/unlink
with POSIX semantics. Strange enough, the POSIX_UNLINK_RENAME filesystem
flag is still set...
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Useless indirection. Rename _unlink_nt back to unlink_nt
and call the function directly with `sharable' flag as needed.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Remove old 'kludge' code which does not seem necessary anymore. The
comment of the 'kludge' is as follows.
* syscalls.cc (setsid): On second thought, in the spirit of keeping
things kludgy, set ctty to -2 here as a special flag, and...
(open): ...only eschew setting O_NOCTTY when that case is detected.
Fixes: c38a2d8373
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
This patch replaces ctty constants with more descriptive macros
(CTTY_UNINITIALIZED and CTTY_RELEASED) rather than -1 and -2 as
well as checking sign with CTTY_IS_VALID().
Fixes: 3b7df69aaa (Cygwin: ctty: Add comments for the special values: -1 and -2.)
Suggested-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
_pinfo::ctty has two special values other than the device id of
the allocated ctty:
-1: CTTY is not initialized yet. Can be associated with the TTY
which is associated with the session leader.
-2: CTTY has been released by setsid(). Can be associate only with
new TTY which is not associated with any other session as CTTY,
but cannot be associate with the TTYs already associated with
other sessions.
This patch adds the comments in some source files.
Suggested-by: Corinna Vinschen <corinna@vinschen.de>
Signedoff-by: Takashi Yano <takashi.yano@nifty.ne.jp>
.com is a remnant from the past. There are only five executables
left:
chcp.com
format.com
mode.com
more.com
tree.com
Calling them on the command line already requires to use the
suffix anyway. So drop useless .com test from the execve test
for scripts (they are handled earlier in the same function
as executables) and do not handle them like .exe suffixes in
other functions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This reverts commit d9e9c7b5a7. The latter added ".dll" to the
blessed_executable_suffixes array because on 32-bit Windows, the
GetBinaryType function would report that a 64-bit DLL is an
executable, contrary to the documentation of that function.
That anomaly does not exist on 64-bit Windows, so we can remove ".dll"
from the list. Reverting the commit does, however, change the
behavior of the rename(2) syscall in the following unlikely situation:
Suppose we have an executable foo.exe and we make the call
rename ("foo", "bar.dll");
Previously, foo.exe would be renamed to bar.dll. So bar.dll would
then be an executable without the .exe extension. The new behavior is
that foo.exe will be renamed to bar.dll.exe. [Exception: If there
already existed an executable (not a DLL!) with the name bar.dll, then
.exe will not be appended.]
The actual reason for these wrappers are lost in time, there's no
hint even in the pre-2000 ChangeLog files. Apparently they were
masking the prototypes or, alternatively, macros from newlib to
clash with the definitions in syscalls.cc.
They are not needed anymore, so just drop them.
This uncovered that the buffer pointer to pwrite is erronously
non-const. Fix this on the way out.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Given that 64 bit Cygwin defines all file access types (off_t,
fpos_t, and derived types) as 64 bit anyway, there's no reason
left to rely on the stdio64 part of newlib. Use base functions
and base types.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Back in early Cygwin development a function based access to the
environment was exported, the internal environ in Cygwin was called
__cygwin_environ and cur_environ() was used to access the environment
indirectly . The history of that necessity is not documented,
but kept in i686 for backward compatibility.
The x86_64 port eventually used __cygwin_environ directly and exported
it as DATA under the usual name environ.
We don't need the i686 workaround anymore, so just rename
__cygwin_environ to environ, drop the cur_environ() macro and
simply export environ under its own name.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Add a _REENT_ERRNO() macro to encapsulate the access to the
_errno member of struct reent. This will help to replace the
structure member with a thread-local storage object in a follow
up patch.
Replace uses of __errno_r() with _REENT_ERRNO(). Keep __errno_r() macro for
potential users outside of Newlib.
Remove "32" or "64" from each of the following names: acl32,
aclcheck32, aclfrommode32, aclfrompbits32, aclfromtext32, aclsort32,
acltomode32, acltopbits32, acltotext32, facl32, fchown32, fcntl64,
fstat64, _fstat64, _fstat64_r, ftruncate64, getgid32, getgrent32,
getgrgid32, getgrnam32, getgroups32, getpwuid32, getpwuid_r32,
getuid32, getuid32, initgroups32, lseek64, lstat64, mknod32, mmap64,
setegid32, seteuid32, setgid32, setgroups32, setregid32, setreuid32,
setuid32, stat64, _stat64_r, truncate64.
Remove prototypes and macro definitions of these names.
Remove "#ifndef __INSIDE_CYGWIN__" from some headers so that the new
names will be available when compiling Cygwin.
Remove aliases that are no longer needed.
Include <unistd.h> in fhandler_clipboard.cc for the declarations of
geteuid and getegid.
Remove the definitions of the following: acl, aclcheck, aclfrommode,
aclfrompbits, aclfromtext, aclsort, acltomode, acltopbits, acltotext,
chown, fchown, _fcntl, fstat, _fstat_r, ftruncate, getegid, geteuid, getgid,
getgrent, getgrgid, getgrnam, getgroups, getpwduid, getpwuid,
getpwuid_r, getuid, initgroups, lacl, lacl32, lchown, lseek, lstat,
mknod, mmap, setegid, seteuid, setgid, setgroups, setregid, setreuid,
setuid, stat, _stat_r, truncate.
[For most of these, the corresponding 64-bit entry points are obtained
by exporting aliases. For example, acl is an alias for acl32, and
truncate is an alias for truncate64.]
Remove the following structs and all code using them (which is 32-bit
only): __stat32, __group16, __flock32, __aclent16_t.
Remove the typedefs of __blkcnt32_t __dev16_t, __ino32_t, which are
used only in code that has been removed.
Put the typedefs of __uid16_t and __gid16_t in one header, instead of
one header if __INSIDE_CYGWIN__ is defined and a different header
otherwise.
The current definition of mknod in syscalls.cc has a third argument of
type __dev16_t instead of dev_t. Fix this on 64-bit Cygwin by making
the existing mknod 32-bit only and then exporting mknod as an alias
for mknod32. (No fix is needed on 32-bit because mknod is redirected
to mknod32 via NEW_FUNCTIONS in Makefile.am.)
Addresses: https://cygwin.com/pipermail/cygwin-developers/2022-May/012589.html
Given we only called create_token on W7 WOW64 anyway, we can now
drop this function and all other functions only called from there
entirely.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Added a new global __sglue object for all configurations.
Decouples the global file object list from the _GLOBAL_REENT
structure by using this new object instead of the __sglue member
of _GLOBAL_REENT in __sfp() and _fwalk_sglue().
Replaced _fwalk_reent() with _fwalk_sglue(). The change adds an
extra __sglue object as a parameter, which will allow the passing
of a global __sglue object separate from the __sglue member of
struct _reent. The global __sglue object will be added in a
follow-on patch.
isabspath handles a path "X:", without trailing slash or backslash,
as absolute path. This breaks some scenarios with relative paths
starting with "X:". For instance, fstatat will mishandle a call
with valid dirfd and "c:" as path.
The reason is that gen_full_path_at() will check for isabspath("C:")
which returns true. So the path will be used verbatim in fstatat,
rather than being converted to a path "<dirfd-path>/c:".
So, introduce isabspath_strict, which returns true for paths starting
with "X:" only if the next char is actually a slash or backslash.
Use it from gen_full_path_at().
This still fixes only half the problem. The right thing would have been
to disallow using DOS paths in the first place. Unfortunately it's much
too late for that.
Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249837.html
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- Currently, the stderr handle is duplicated in close_all_files().
This interferes the handle counting for detecting closure of read
pipe, which is introduced by commit f79a4611. This patch stops
duplicating stderr handle if it is write pipe.
I wasted valuable minutes of my life just to find out why we export
this weird version of pipe. In the pre-2000 era the idea was Cygwin
could be used as drop-in replacement for msvcrt.dll, apparently.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Due to reports on the Cygwin mailing list[1][2], it was uncovered
that a NtOpenDirectoryObject/NtQueryDirectoryObject/NtClose sequence
with NtQueryDirectoryObject iterating over the directory entries,
one entry per invocation, is not running atomically. If new entries
are inserted into the queried directory, other entries may be moved
around and then accidentally show up twice while iterating.
Change (almost) all NtQueryDirectoryObject invocations so that it gets
a really big buffer (64K) and ideally fetches all entries at once.
This appears to work atomically.
"Almost" all, because fhandler_procsys::readdir can't be easily changed.
[1] https://cygwin.com/pipermail/cygwin/2021-July/248998.html
[2] https://cygwin.com/pipermail/cygwin/2021-August/249124.html
Fixes: e9c8cb3193 ("(format_proc_partitions): Revamp loop over existing harddisks by scanning the NT native \Device object directory and looking for Harddisk entries.")
Fixes: a998dd7055 ("Implement advisory file locking.")
Fixes: 3b7cd74bfd ("(winpids::enum_processes): Fetch Cygwin processes from listing of shared cygwin object dir in the native NT namespace.")
Fixes: 0d6f2b0117 ("syscalls.cc (sync_worker): Rewrite using native NT functions.")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
linkat(olddirfd, oldpath, oldname, newdirfd, newname, AT_EMPTY_PATH)
is supposed to create a link to the file referenced by olddirfd if
oldname is the empty string. Currently this is done via the /proc
filesystem by converting the call to
linkat(AT_FDCWD, "/proc/self/fd/<olddirfd>", newdirfd, newname,
AT_SYMLINK_FOLLOW),
which ultimately leads to a call to the appropriate fhandler's link
method. Simplify this by using cygheap_fdget to obtain the fhandler
directly.
When a FIFO is opened, syscalls.cc:open always calls fstat on the
newly-created fhandler_fifo. This results from a call to
device_access_denied.
To speed-up this fstat call, and therefore the open(2) call, use
PC_KEEP_HANDLE when the fhandler is created. The resulting
conv_handle is retained until after the fstat call if the fhandler is
a FIFO; otherwise, it is closed immediately.
Per discussion on cygwin-developers, a Cygwin tmpfile(3) implementation
has been added to syscalls.cc. This overrides the one supplied by
newlib. Then the open(2) flag O_TMPFILE was added to the open call that
tmpfile internally makes.
This v2 patch removes O_CREAT from open() call as O_TMPFILE obviates it.
Note that open() takes a directory's path but returns an fd to a file.
Replace all occurrences of OPEN_MAX_MAX by OPEN_MAX, and define the
latter to be 3200, which was the value of the former. In view of the
recent change to getdtablesize, there is no longer a need to
distinguish between these two macros.
According to the Linux man page for getdtablesize(3), the latter is
supposed to return "the maximum number of files a process can have
open, one more than the largest possible value for a file descriptor."
The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we
now return that.
Previously getdtablesize returned the current size of cygheap->fdtab,
Cygwin's internal file descriptor table. But this is a dynamically
growing table, and its current size does not reflect an actual limit
on the number of open files.
With this change, gnulib now reports that getdtablesize and
fcntl(F_DUPFD) work on Cygwin. Packages like GNU tar that use the
corresponding gnulib modules will no longer use gnulib replacements on
Cygwin.
Allow fchmodat with the AT_SYMLINK_NOFOLLOW flag to succeed on
non-symlinks. Previously it always failed, as it does on Linux. But
POSIX permits it to succeed on non-symlinks even if it fails on
symlinks.
The reason for following POSIX rather than Linux is to make gnulib
report that fchmodat works on Cygwin. This improves the efficiency of
packages like GNU tar that use gnulib's fchmodat module. Previously
such packages would use a gnulib replacement for fchmodat on Cygwin.
I think we don't need an extra flag as we can utilize: access & FILE_WRITE_ATTRIBUTES
What do you think?
Ben Wijen (1):
syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE
winsup/cygwin/ntdll.h | 3 ++-
winsup/cygwin/syscalls.cc | 22 +++++++--------
winsup/cygwin/wincap.cc | 11 ++++++++
winsup/cygwin/wincap.h | 56 ++++++++++++++++++++-------------------
4 files changed, 53 insertions(+), 39 deletions(-)
--
2.30.0
>From 2d0ff6fec10d03c24d11c747852018b7bc1136ac Mon Sep 17 00:00:00 2001
In-Reply-To: <20210122105201.GD810271@calimero.vinschen.de>
References: <20210122105201.GD810271@calimero.vinschen.de>
From: Ben Wijen <ben@wijen.net>
Date: Tue, 17 Dec 2019 15:15:25 +0100
Subject: [PATCH v3 1/8] syscalls.cc: unlink_nt: Try
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE
Implement wincap.has_posix_unlink_semantics_with_ignore_readonly and when set
skip setting/clearing of READONLY attribute and instead use
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE
Move post-dir unlink check from fhandler_disk_file::rmdir to
_unlink_nt_post_dir_check
If a directory is not removed through fhandler_disk_file::rmdir
we can now make sure the post dir check is performed.
Yoshinao Muramatsu
Corinna Vinschen
Takashi Yano
Ken Brown
Matt Joyce
Sebastian Huber
Mark Geisert
Ben Wijen