Re: GDB and thread
Am 29.12.2019 um 05:38 schrieb Brian Inglis: On 2019-12-28 15:28, Marco Atzeri wrote: Am 28.12.2019 um 23:03 schrieb Ken Brown: On 12/28/2019 4:27 PM, Marco Atzeri wrote: I am trying to debug the libuv test failures, but it seems I am not able to convince GDB on stopping just before the failure. Is "thread apply all" working on Cygwin ? The fact that produces no output in comparison to a normal break command is a bit strange (gdb) break test-dlerror.c:34 Breakpoint 1 at 0x10040b0b0: file /pub/devel/libuv/libuv-1.34.0/test/test-dlerro r.c, line 34. (gdb) thread apply all break test-dlerror.c:34 Might this be related to optimization? That could change the order in which lines of code are executed. Have you tried building without optimization? Already thought, but it is built with -ggdb -O0 Recommended to use at least -Og nowadays for better debugging: $ info gcc inv debug "With no '-O' option at all, some compiler passes that collect information useful for debugging do not run at all, so that '-Og' may result in a better debugging experience." Thanks for the info unfortunately there is no difference. It is like the debugger is unable to see the breakpoints when running in this threaded code. Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 3.1.2 + Windows 10 Home Build 10.0.18362 - alt+space hotkeys not working
On 2019-12-28 05:04, Takashi Yano wrote: > On Fri, 27 Dec 2019 12:19:53 +0500, Eugene Klimov wrote: >> i don't use ConEmu >> but after upgrade to cygwin 3.1 this team have same bugs > > These are not the same issue at all. As for alt-space, > the keycode 0x1b 0x20 is passed to the cygwin application > correctly inside of console window. This is not a bug. > > The issue of ConEmu is that the no key code is passed > by arrow keys or del key to the cygwin application. > >> also rollback cygwin to 3.0 return previous behaviors >> and GNU `screen` inside cygwin `ssh` works fine > > I cannot get what is your problem. I logged in to a linux > machine using cygwin ssh and start GNU screen in the ssh > session, however, everything works fine for me. I tried > that in both mintty and command prompt. > > *Please* let us know the *detail* of the steps to reproduce > your issue and what happens. He is using some Cyrillic locale: https://monosnap.com/file/gBqrKZLH4zhquuNWPSTJfHRMJzlMq8 so some more details might help from: $ mintty -V Ignoring unknown option 'CharNarrowing'. mintty 3.0.2 (x86_64-pc-cygwin) © 2013/2019 Andy Koppe / Thomas Wolff License GPLv3+: GNU GPL version 3 or later There is no warranty, to the extent permitted by law. $ echo $LANGUAGE en_CA:en_GB:en $ for o in -s -u -f -i -n ''; do locale $o; done en_US en_US en_CA en_CA en_CA LANG=en_CA.UTF-8 LC_CTYPE="en_CA.UTF-8" LC_NUMERIC="en_CA.UTF-8" LC_TIME="en_CA.UTF-8" LC_COLLATE="en_CA.UTF-8" LC_MONETARY="en_CA.UTF-8" LC_MESSAGES="en_CA.UTF-8" LC_ALL= -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GDB and thread
On 2019-12-28 15:28, Marco Atzeri wrote: > Am 28.12.2019 um 23:03 schrieb Ken Brown: >> On 12/28/2019 4:27 PM, Marco Atzeri wrote: >>> I am trying to debug the libuv test failures, >>> but it seems I am not able to convince GDB on stopping >>> just before the failure. >>> >>> Is "thread apply all" working on Cygwin ? >>> The fact that produces no output in comparison to >>> a normal break command is a bit strange >>> >>> (gdb) break test-dlerror.c:34 >>> Breakpoint 1 at 0x10040b0b0: file >>> /pub/devel/libuv/libuv-1.34.0/test/test-dlerro >>> r.c, line 34. >>> (gdb) thread apply all break test-dlerror.c:34 >> >> Others know this better than I do, but I seem to recall that a break command >> automatically applies to all threads. In other words, "thread apply all" is >> redundant. > > It seems to ignore any break for what I see. > thread apply all was a tentative after simple break was ineffective >>> Any hint will be appreciated >> >> Might this be related to optimization? That could change the order in which >> lines of code are executed. Have you tried building without optimization? > > Already thought, but it is built with -ggdb -O0 Recommended to use at least -Og nowadays for better debugging: $ info gcc inv debug "With no '-O' option at all, some compiler passes that collect information useful for debugging do not run at all, so that '-Og' may result in a better debugging experience." -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Any downside to using winsymlinks over cygwin-style symlinks?
See comments inline Andrey Repin wrote at about 21:11:55 +0300 on Friday, December 27, 2019: > Greetings, Jeff! > > > Based on the documentation and practical use of the Windows-style > > symlinks (winsymlinks) vs Cygwin-style symlinks, it seems to me that: > > 1. Winsymlinks have the advantage of working as symlinks/shortcuts > >under both Cygwin and Windows Explorer while Cygwin links are > >recognized only in Cygwin > > True. > > > 2. They both are basically text files with some MAGIC numbers and > >attributes that allow them to be interpreted as symlinks > > NOT true. > Windows native symlinks are actual FS objects. CYGWIN=winsymlinks is the same as CYGWIN=winsymlinks:lnk This corresponds to Windows-style links, not native Windows symlinks. You are referring to CYGWIN=winsymlinks:native or CYGWIN=winsymlinks:nativestrict which refers to the true FS object symlinks > > > So, is there any *disadvantage* to always using Winsymlinks and indeed > > converting my old Cygwin-style links to Windows-style? > > You can't create native symlinks as a member of Administrators group, even if > your account have the needed privilege. Again note the distinction between winsymlinks and winsymlinks:native > > > (Note: I can't use Windows Native symlinks because I don't have admin > > privileges on all my machines) > > Exactly. > > > Finally, where is the best place to set CYGWIN=winsymlinks? > > In .bash_profile? > > If you can't use them, there's no reason to set this option, if you expect > interoperability between Windows and Cygwin. Again note the distinction between winsymlinks and winsymlinks:native I was referring winsymlinks (or more pedantically winsymlinks:lnk) > With just winsymlinks set, Cygwin will try to create native symlink, > but failing that, it will create regular Cygwin symlink. > > With winsymlinks:nativestrict set, Cygwin will try to create native symlink > and report failure instead of creating Cygwin symlink. > > P.S. > I'm using winsymlinks:nativestrict personally, but I know implications and > well prepared to deal with them. > > > -- > With best regards, > Andrey Repin > Friday, December 27, 2019 21:04:24 > > Sorry for my terrible english... > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GDB and thread
Am 28.12.2019 um 23:03 schrieb Ken Brown: On 12/28/2019 4:27 PM, Marco Atzeri wrote: Hi, I am trying to debug the libuv test failures, but it seems I am not able to convince GDB on stopping just before the failure. Is "thread apply all" working on Cygwin ? The fact that produces no output in comparison to a normal break command is a bit strange (gdb) break test-dlerror.c:34 Breakpoint 1 at 0x10040b0b0: file /pub/devel/libuv/libuv-1.34.0/test/test-dlerro r.c, line 34. (gdb) thread apply all break test-dlerror.c:34 Others know this better than I do, but I seem to recall that a break command automatically applies to all threads. In other words, "thread apply all" is redundant. It seems to ignore any break for what I see. thread apply all was a tentative after simple break was ineffective (gdb) run dlerror Starting program: /cygdrive/d/cyg_pub/devel/libuv/libuv-1.34.0-build/test/.libs/ run-tests.exe dlerror [New Thread 139176.0x231a0] [New Thread 139176.0x231c8] [New Thread 139176.0x21a0c] [New Thread 139176.0x2332c] [New Thread 139176.0x230b0] [New Thread 139176.0x231cc] [New Thread 139176.0x23028] [New Thread 139176.0x23214] [Thread 139176.0x23028 exited with code 0] not ok 1 - dlerror # exit code 134 # Output from process `dlerror`: # Assertion failed in /pub/devel/libuv/libuv-1.34.0/test/test-dlerror.c on line 45: strstr(msg, path) != NULL [Thread 139176.0x231c8 exited with code 134] [Thread 139176.0x230b0 exited with code 134] [Thread 139176.0x2332c exited with code 134] [Thread 139176.0x23214 exited with code 134] [Thread 139176.0x21a0c exited with code 134] [Inferior 1 (process 139176) exited with code 0206] (gdb) Any hint will be appreciated Might this be related to optimization? That could change the order in which lines of code are executed. Have you tried building without optimization? Already thought, but it is built with -ggdb -O0 Ken Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Warning: Cannot convert string "xlogo32" to type Pixmap
The xlogo application produces this warning message: Warning: Cannot convert string "xlogo32" to type Pixmap This is because /etc/X11/app-defaults/XLogo specifies XLogo*iconPixmap:xlogo32 XLogo*iconMask: xlogo32 which causes xlogo to look for /usr/include/X11/bitmaps/xlogo32 which doesn't exist -- unless you install the separate "xbitmaps" package. Installing xbitmaps makes the warning go away. $ cygcheck -f /usr/bin/xlogo.exe /usr/include/X11/bitmaps/xlogo32 xbitmaps-1.1.2-1 xlogo-1.0.5-1 xlogo is the only application (at least of the ones I have on my system) that specifies an iconPixmap in its app-defaults file. Suggested fix: Add a dependency so installing xlogo automatically installs xbitmaps. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GDB and thread
On 12/28/2019 4:27 PM, Marco Atzeri wrote: > Hi, > I am trying to debug the libuv test failures, > but it seems I am not able to convince GDB on stopping > just before the failure. > > Is "thread apply all" working on Cygwin ? > The fact that produces no output in comparison to > a normal break command is a bit strange > > (gdb) break test-dlerror.c:34 > Breakpoint 1 at 0x10040b0b0: file > /pub/devel/libuv/libuv-1.34.0/test/test-dlerro > r.c, line 34. > (gdb) thread apply all break test-dlerror.c:34 Others know this better than I do, but I seem to recall that a break command automatically applies to all threads. In other words, "thread apply all" is redundant. > (gdb) run dlerror > Starting program: > /cygdrive/d/cyg_pub/devel/libuv/libuv-1.34.0-build/test/.libs/ > run-tests.exe dlerror > [New Thread 139176.0x231a0] > [New Thread 139176.0x231c8] > [New Thread 139176.0x21a0c] > [New Thread 139176.0x2332c] > [New Thread 139176.0x230b0] > [New Thread 139176.0x231cc] > [New Thread 139176.0x23028] > [New Thread 139176.0x23214] > [Thread 139176.0x23028 exited with code 0] > not ok 1 - dlerror > # exit code 134 > # Output from process `dlerror`: > # Assertion failed in /pub/devel/libuv/libuv-1.34.0/test/test-dlerror.c on > line > 45: strstr(msg, path) != NULL > [Thread 139176.0x231c8 exited with code 134] > [Thread 139176.0x230b0 exited with code 134] > [Thread 139176.0x2332c exited with code 134] > [Thread 139176.0x23214 exited with code 134] > [Thread 139176.0x21a0c exited with code 134] > [Inferior 1 (process 139176) exited with code 0206] > (gdb) > > > Any hint will be appreciated Might this be related to optimization? That could change the order in which lines of code are executed. Have you tried building without optimization? Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
GDB and thread
Hi, I am trying to debug the libuv test failures, but it seems I am not able to convince GDB on stopping just before the failure. Is "thread apply all" working on Cygwin ? The fact that produces no output in comparison to a normal break command is a bit strange (gdb) break test-dlerror.c:34 Breakpoint 1 at 0x10040b0b0: file /pub/devel/libuv/libuv-1.34.0/test/test-dlerro r.c, line 34. (gdb) thread apply all break test-dlerror.c:34 (gdb) run dlerror Starting program: /cygdrive/d/cyg_pub/devel/libuv/libuv-1.34.0-build/test/.libs/ run-tests.exe dlerror [New Thread 139176.0x231a0] [New Thread 139176.0x231c8] [New Thread 139176.0x21a0c] [New Thread 139176.0x2332c] [New Thread 139176.0x230b0] [New Thread 139176.0x231cc] [New Thread 139176.0x23028] [New Thread 139176.0x23214] [Thread 139176.0x23028 exited with code 0] not ok 1 - dlerror # exit code 134 # Output from process `dlerror`: # Assertion failed in /pub/devel/libuv/libuv-1.34.0/test/test-dlerror.c on line 45: strstr(msg, path) != NULL [Thread 139176.0x231c8 exited with code 134] [Thread 139176.0x230b0 exited with code 134] [Thread 139176.0x2332c exited with code 134] [Thread 139176.0x23214 exited with code 134] [Thread 139176.0x21a0c exited with code 134] [Inferior 1 (process 139176) exited with code 0206] (gdb) Any hint will be appreciated Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia
On 12/28/19, Andrey Repin wrote: > Greetings, Peter Binney! > > Bottom posting in this list, please. > >> Hello Andrey - many thanks again. > >> I have added noacl to the default fstab entry, so it reads: >> none /cygdrive cygdrive noacl,binary,posix=0,user 0 0 > >> and that sorts out the permissions problem, thank you. > >> But, bizarrely, it introduced a new one - the WHICH command no longer >> reports non-executable files on the PATH. Try adding the exec option to fstab: $ grep cygdrive /etc/fstab # none /cygdrive cygdrive binary,posix=0,user 0 0 none /cygdrive cygdrive binary,posix=0,user,noacl,exec 0 0 $ which xcopy /cygdrive/c/windows/system32/xcopy $ ls -l /cygdrive/c/windows/system32/xcopy -rwxr-xr-x 2 Lee None 47616 Sep 15 2018 /cygdrive/c/windows/system32/xcopy.exe Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[PATCH 0/3] Support opening a symlink with O_PATH | O_NOFOLLOW
Currently, opening a symlink with O_NOFOLLOW fails with ELOOP. Following Linux, the first patch in this series allows the call to succeed if O_PATH is also specified. According to the Linux man page for 'open', the file descriptor returned by the call should be usable as the dirfd argument in calls to fchownat, fstatat, and readlinkat with an empty pathname, to have the calls operate on the symbolic link. The second and third patches achieve this. For fchownat and fstatat, we do this by adding support for the AT_EMPTY_PATH flag. [The man page mentions linkat also, but it already supports the AT_EMPTY_PATH flag.] Ken Brown (3): Cygwin: allow opening a symlink with O_PATH | O_NOFOLLOW Cygwin: readlinkat: allow pathname to be empty Cygwin: fchownat and fstatat: support the AT_EMPTY_PATH flag winsup/cygwin/syscalls.cc | 51 +-- 1 file changed, 38 insertions(+), 13 deletions(-) -- 2.21.0
[PATCH 3/3] Cygwin: fchownat and fstatat: support the AT_EMPTY_PATH flag
Following Linux, allow the pathname argument to be empty if the
AT_EMPTY_PATH is specified. In this case the dirfd argument can refer
to any type of file, not just a directory, and the call operates on
that file. In particular, dirfd can refer to a symlink that was
opened with O_PATH and O_NOFOLLOW.
Add a new optional argument to gen_full_path_at to help implement
this.
---
winsup/cygwin/syscalls.cc | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 2be8693c9..1bc856268 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -4635,7 +4635,8 @@ pclose (FILE *fp)
static int
gen_full_path_at (char *path_ret, int dirfd, const char *pathname,
- bool null_pathname_allowed = false)
+ bool null_pathname_allowed = false,
+ bool at_empty_path_flag = false)
{
/* Set null_pathname_allowed to true to allow GLIBC compatible behaviour
for NULL pathname. Only used by futimesat. */
@@ -4644,20 +4645,25 @@ gen_full_path_at (char *path_ret, int dirfd, const char
*pathname,
set_errno (EFAULT);
return -1;
}
+ bool empty_path = false;
if (pathname)
{
if (!*pathname)
{
- set_errno (ENOENT);
- return -1;
+ empty_path = true;
+ if (!at_empty_path_flag)
+ {
+ set_errno (ENOENT);
+ return -1;
+ }
}
- if (strlen (pathname) >= PATH_MAX)
+ else if (strlen (pathname) >= PATH_MAX)
{
set_errno (ENAMETOOLONG);
return -1;
}
}
- if (pathname && isabspath (pathname))
+ if (pathname && !empty_path && isabspath (pathname))
stpcpy (path_ret, pathname);
else
{
@@ -4674,12 +4680,14 @@ gen_full_path_at (char *path_ret, int dirfd, const char
*pathname,
cygheap_fdget cfd (dirfd);
if (cfd < 0)
return -1;
- if (!cfd->pc.isdir ())
+ if (!empty_path && !cfd->pc.isdir ())
{
set_errno (ENOTDIR);
return -1;
}
p = stpcpy (path_ret, cfd->get_name ());
+ if (empty_path)
+ return 0;
}
if (!p)
{
@@ -4785,13 +4793,14 @@ fchownat (int dirfd, const char *pathname, uid_t uid,
gid_t gid, int flags)
tmp_pathbuf tp;
__try
{
- if (flags & ~AT_SYMLINK_NOFOLLOW)
+ if (flags & ~(AT_SYMLINK_NOFOLLOW | AT_EMPTY_PATH))
{
set_errno (EINVAL);
__leave;
}
char *path = tp.c_get ();
- if (gen_full_path_at (path, dirfd, pathname))
+ if (gen_full_path_at (path, dirfd, pathname, false,
+ flags & AT_EMPTY_PATH))
__leave;
return chown_worker (path, (flags & AT_SYMLINK_NOFOLLOW)
? PC_SYM_NOFOLLOW : PC_SYM_FOLLOW, uid, gid);
@@ -4808,13 +4817,14 @@ fstatat (int dirfd, const char *__restrict pathname,
struct stat *__restrict st,
tmp_pathbuf tp;
__try
{
- if (flags & ~AT_SYMLINK_NOFOLLOW)
+ if (flags & ~(AT_SYMLINK_NOFOLLOW | AT_EMPTY_PATH))
{
set_errno (EINVAL);
__leave;
}
char *path = tp.c_get ();
- if (gen_full_path_at (path, dirfd, pathname))
+ if (gen_full_path_at (path, dirfd, pathname, false,
+ flags & AT_EMPTY_PATH))
__leave;
path_conv pc (path, ((flags & AT_SYMLINK_NOFOLLOW)
? PC_SYM_NOFOLLOW : PC_SYM_FOLLOW)
--
2.21.0
[PATCH 2/3] Cygwin: readlinkat: allow pathname to be empty
Following Linux, allow the pathname argument to be an empty string,
provided the dirfd argument refers to a symlink opened with O_PATH and
O_NOFOLLOW. The readlinkat call then operates on that symlink.
---
winsup/cygwin/syscalls.cc | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 038a316db..2be8693c9 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -4979,8 +4979,23 @@ readlinkat (int dirfd, const char *__restrict pathname,
char *__restrict buf,
__try
{
char *path = tp.c_get ();
- if (gen_full_path_at (path, dirfd, pathname))
- __leave;
+ int res = gen_full_path_at (path, dirfd, pathname);
+ if (res)
+ {
+ if (errno != ENOENT)
+ __leave;
+ /* pathname is an empty string. This is OK if dirfd refers
+to a symlink that was opened with O_PATH and O_NOFOLLOW.
+In this case, readlinkat operates on the symlink. */
+ cygheap_fdget cfd (dirfd);
+ if (cfd < 0)
+ __leave;
+ if (!(cfd->issymlink ()
+ && cfd->get_flags () & O_PATH
+ && cfd->get_flags () & O_NOFOLLOW))
+ __leave;
+ strcpy (path, cfd->get_name ());
+ }
return readlink (path, buf, bufsize);
}
__except (EFAULT) {}
--
2.21.0
[PATCH 1/3] Cygwin: allow opening a symlink with O_PATH | O_NOFOLLOW
Up to now, opening a symlink with O_NOFOLLOW fails with ELOOP.
Following Linux, allow this to succeed if O_PATH is also specified.
---
winsup/cygwin/syscalls.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 20126ce10..038a316db 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -1470,7 +1470,7 @@ open (const char *unix_path, int flags, ...)
if (!(fh = build_fh_name (unix_path, opt, stat_suffixes)))
__leave;/* errno already set */
- if ((flags & O_NOFOLLOW) && fh->issymlink ())
+ if ((flags & O_NOFOLLOW) && fh->issymlink () && !(flags & O_PATH))
{
set_errno (ELOOP);
__leave;
--
2.21.0
Re: mintty window flashes open and immediately closes
FWIW, this problem has disappeared with the latest setup.exe.
There are no more errors during postinstall and AFAICT everything is working.
On Sat, Dec 21, 2019, at 4:58 PM, Jay Goldman wrote:
> I think my problem applies to this thread.
> (I'm unclear how to reply to an entry in the mailing list archive)
>
>
> all cygwin commands stopped working for me, too.
> (i have been using cygwin for many years, it has been running on my
> windows 10 system for as long as windows 10 has been available)
> so, i recovered a version of the bin folder from a few days ago, and
> all is working. (note, i only had to recover the bin folder, i did not
> have to recover the lib, etc, or var folders)
>
> not sure if i ran cygcheck correctly - i ran it from a cmd window in a
> non-cygwin folder (this is newcheck.out)
> so i ran it again (badcheck.out) while working dir is \bin.bad (my
> 'bad' version of \bin folder)
> NOTE: i changed the user name changed to )
>
> Before backing up the bin folder, the situation was:
> When i run cmd window and try anything in cygwin bin folder i get
> (bash.exe is just an example) (except for cygcheck :-)
> C:\newbin>bash.exe -i
> 0 [main] bash (1588) C:\newbin\bash.exe: *** fatal error -
> add_item ("\??\C:", "/", ...) failed, errno 22
>
> This also happens with bat scripts i have been using for many years to
> start xwindows or just a terminal window.
>
> It appears, i think, to be a problem with setup (or maybe an
> interaction with some recent windows 10 update?),
> since when i run setup-x86_64.exe, i get the following in
> /var/log/setup.log:
>
> 2019/12/21 13:48:56 Starting cygwin install, version 2.897
> 2019/12/21 13:48:56 User has backup/restore rights
> 2019/12/21 13:48:56 Current Directory: K:\installation_disks\cygwin64
> 2019/12/21 13:48:56 Could not open service McShield for query, start
> and stop. McAfee may not be installed, or we don't have access.
> 2019/12/21 13:49:01 source: network install
> 2019/12/21 13:49:02 root: C:\ system
> 2019/12/21 13:49:03 Selected local directory:
> K:\installation_disks\cygwin64
> 2019/12/21 13:49:04 net: Direct
> 2019/12/21 13:49:06 site: http://mirror.clarkson.edu/cygwin/
> 2019/12/21 13:49:06 HTTP status 404 fetching
> http://mirror.clarkson.edu/cygwin/x86_64/setup.zst.sig
> 2019/12/21 13:49:06 HTTP status 404 fetching
> http://mirror.clarkson.edu/cygwin/x86_64/setup.zst
> 2019/12/21 13:49:08 solving: 0 tasks, update: yes, use test packages: no
> 2019/12/21 13:49:11 solving: 0 tasks, update: no, use test packages: no
> 2019/12/21 13:49:11 Augmented Transaction List: is empty
> 2019/12/21 13:49:13 Changing gid back to original
> 2019/12/21 13:49:13 running: C:\\bin\dash.exe
> "/etc/postinstall/0p_000_autorebase.dash"
> 2019/12/21 13:49:15 abnormal exit: exit code=-1073741819
> 2019/12/21 13:49:15 running: C:\\bin\dash.exe
> "/etc/postinstall/0p_texlive_prep.dash"
> 2019/12/21 13:49:18 abnormal exit: exit code=-1073741819
> 2019/12/21 13:49:18 running: C:\\bin\dash.exe
> "/etc/postinstall/0p_update-info-dir.dash"
> 2019/12/21 13:49:19 abnormal exit: exit code=-1073741819
> 2019/12/21 13:49:22 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/bash.sh"
> 2019/12/21 13:49:23 abnormal exit: exit code=256
> 2019/12/21 13:49:23 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/cygwin-doc.sh"
> 2019/12/21 13:49:26 abnormal exit: exit code=256
> 2019/12/21 13:49:26 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/lyx.sh"
> 2019/12/21 13:49:28 abnormal exit: exit code=256
> 2019/12/21 13:49:28 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/TeXmacs.sh"
> 2019/12/21 13:49:29 abnormal exit: exit code=256
> 2019/12/21 13:49:29 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/zp_adwaita-icon-theme.sh"
> 2019/12/21 13:49:31 abnormal exit: exit code=256
> 2019/12/21 13:49:31 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/zp_desktop-file-utils.sh"
> 2019/12/21 13:49:33 abnormal exit: exit code=256
> 2019/12/21 13:49:33 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/zp_fontconfig_cache_1.sh"
> 2019/12/21 13:49:35 abnormal exit: exit code=256
> 2019/12/21 13:49:35 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/zp_glib2.0.sh"
> 2019/12/21 13:49:38 abnormal exit: exit code=256
> 2019/12/21 13:49:38 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/zp_hicolor-icon-theme.sh"
> 2019/12/21 13:49:40 abnormal exit: exit code=256
> 2019/12/21 13:49:40 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/zp_man-db.sh"
> 2019/12/21 13:49:42 abnormal exit: exit code=256
> 2019/12/21 13:49:42 running: C:\\bin\dash.exe
> "/etc/postinstall/zp_octave_finish.dash"
> 2019/12/21 13:49:44 abnormal exit: exit code=-1073741819
> 2019/12/21 13:49:44 running: C:\\bin\bash.exe --norc --noprofile
> "/etc/postinstall/zp_shared-mime-info.sh"
> 2019/12/21 13:49:47 abnormal exit:
Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia
Greetings, Peter Binney!
Bottom posting in this list, please.
> Hello Andrey - many thanks again.
> I have added noacl to the default fstab entry, so it reads:
> none /cygdrive cygdrive noacl,binary,posix=0,user 0 0
> and that sorts out the permissions problem, thank you.
> But, bizarrely, it introduced a new one - the WHICH command no longer
> reports non-executable files on the PATH.
> Such files are found and executed OK (presumably because Windows logic
> is adhered to, where execute permission is not required), but WHICH
> doesn't "see" them.
> So I had to build a work-around for WHICH (which I use in various
> scriptware) since I can also find no way to set the execute bit on a
> file ("chmod a+x" doesn't seem to do anything with or without noacl).
This could be actually because you are lacking executable permission on your
files. Which Windows by default always set.
--
With best regards,
Andrey Repin
Saturday, December 28, 2019 16:57:49
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: setup (2.898)
A new version of Setup (2.898) has been uploaded to: https://cygwin.com/setup-x86_64.exe (64 bit version) https://cygwin.com/setup-x86.exe (32 bit version) Changes compared to 2.897: - '--upgrade-also' will now also upgrade an obsolete package specified on command line (e.g.: setup -q -g -P python3-lxml currently gets you an (empty, obsolete) python3-lxml package, which is replaced by python36-lxml (which obsoletes it) the next time setup is run. After this change, python36-lxml is installed instead) (See also the discussion at https://cygwin.com/ml/cygwin-apps/2017-10/msg00092.html et seq. (where I come to the (incorrect) conclusion that since we don't need this for interactive use, it's not needed) - Remove the 'Bin?' column The only use this column now has is that unticking it is the same as selecting the 'uninstall' action. - Packages can now depend with a version relation on the pseudo-package '_windows' (which has the same version as the Windows we are running on) (This is intended for use with the cygwin package, to prevent updates being installed on Windows versions which it has dropped support for) Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com.
[ANNOUNCEMENT] Updated: setup (2.898)
A new version of Setup (2.898) has been uploaded to: https://cygwin.com/setup-x86_64.exe (64 bit version) https://cygwin.com/setup-x86.exe (32 bit version) Changes compared to 2.897: - '--upgrade-also' will now also upgrade an obsolete package specified on command line (e.g.: setup -q -g -P python3-lxml currently gets you an (empty, obsolete) python3-lxml package, which is replaced by python36-lxml (which obsoletes it) the next time setup is run. After this change, python36-lxml is installed instead) (See also the discussion at https://cygwin.com/ml/cygwin-apps/2017-10/msg00092.html et seq. (where I come to the (incorrect) conclusion that since we don't need this for interactive use, it's not needed) - Remove the 'Bin?' column The only use this column now has is that unticking it is the same as selecting the 'uninstall' action. - Packages can now depend with a version relation on the pseudo-package '_windows' (which has the same version as the Windows we are running on) (This is intended for use with the cygwin package, to prevent updates being installed on Windows versions which it has dropped support for) Please send bug reports, as usual, to the public mailing list cygwin AT cygwin DOT com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia
Hello Andrey - many thanks again.
I have added noacl to the default fstab entry, so it reads:
none /cygdrive cygdrive noacl,binary,posix=0,user 0 0
and that sorts out the permissions problem, thank you.
But, bizarrely, it introduced a new one - the WHICH command no longer
reports non-executable files on the PATH.
Such files are found and executed OK (presumably because Windows logic
is adhered to, where execute permission is not required), but WHICH
doesn't "see" them.
So I had to build a work-around for WHICH (which I use in various
scriptware) since I can also find no way to set the execute bit on a
file ("chmod a+x" doesn't seem to do anything with or without noacl).
Thanks again,
Peter
On Tue, 24 Dec 2019 at 09:20, Andrey Repin wrote:
>
> Greetings, Peter Binney!
>
> > Hello Andrey - many thanks for that. I have now removed /etc/passwd
> > and /etc/group which didn't change anything.
>
> > I read some of your earlier posts on this and had already tried the noacl
> > route.
>
> > Unfortunately it has made no difference. I added a second line to my
> > fstab so it read:
>
> > none /cygdrive cygdrive binary,posix=0,user 0 0
>
> Add "noacl" here.
>
> > e: /cygdrive/e ntfs noacl,binary,posix=0,user,auto 0 0
>
> Avoid overlapping mount points. The end result could be surprising.
>
> > with "mount" showing:
>
> > C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> > C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> > C:/cygwin on / type ntfs (binary,auto)
> > E: on /cygdrive/e type ntfs (binary,noacl,posix=0,user)
> > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> > D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
> > N: on /cygdrive/n type smbfs (binary,posix=0,user,noumount,auto)
> > P: on /cygdrive/p type smbfs (binary,posix=0,user,noumount,auto)
>
> > But when creating files on an E: I still get DENY for "NULL SID" and
> > other accounts.
>
> $ cat /etc/fstab && mount
> # For a description of the file format, see the Users Guide
> # http://cygwin.com/cygwin-ug-net/using.html#mount-table
>
> # This is default anyway:
> #none /cygdrive cygdrive binary,posix=0,user 0 0
> none / cygdrive noacl,binary,nouser,posix=0 0 0
> W:/ /var/run ntfs acl,binary,nouser,posix=0 0 0
> C:/Users /home bind noacl,binary,exec,posix=0 0 0
> none /tmp usertemp binary,nouser,posix=1 0 0
>
> C:/Users/ANRDAE~1/AppData/Local/Temp on /tmp type ntfs (binary,usertemp)
> C:/Programs/Cygwin_64/bin on /usr/bin type ntfs (binary,auto)
> C:/Programs/Cygwin_64/lib on /usr/lib type ntfs (binary,auto)
> C:/Programs/Cygwin_64 on / type ntfs (binary,auto)
> C:/Users on /home type ntfs (binary,exec,noacl,posix=0)
> W: on /var/run type ntfs (binary,posix=0)
> C: on /c type ntfs (binary,noacl,posix=0,noumount,auto)
> M: on /m type vfat (binary,noacl,posix=0,noumount,auto)
> Y: on /y type smbfs (binary,noacl,posix=0,noumount,auto)
> Z: on /z type smbfs (binary,noacl,posix=0,noumount,auto)
>
>
> --
> With best regards,
> Andrey Repin
> Tuesday, December 24, 2019 12:14:33
>
> Sorry for my terrible english...
>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 3.1.2 + Windows 10 Home Build 10.0.18362 - alt+space hotkeys not working
On Fri, 27 Dec 2019 12:19:53 +0500 Eugene Klimov wrote: > i don't use ConEmu > but after upgrade to cygwin 3.1 this team have same bugs These are not the same issue at all. As for alt-space, the keycode 0x1b 0x20 is passed to the cygwin application correctly inside of console window. This is not a bug. The issue of ConEmu is that the no key code is passed by arrow keys or del key to the cygwin application. > also rollback cygwin to 3.0 return previous behaviors > and GNU `screen` inside cygwin `ssh` works fine I cannot get what is your problem. I logged in to a linux machine using cygwin ssh and start GNU screen in the ssh session, however, everything works fine for me. I tried that in both mintty and command prompt. *Please* let us know the *detail* of the steps to reproduce your issue and what happens. -- Takashi Yano -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.1 forcibly set wrong console code page
On Fri, 27 Dec 2019 20:38:31 +0300
Andrey Repin wrote:
> Greetings, All!
>
> Despite having "chcp.com 65001" in .bashrc, current codepage now reset to
> CP1251 (which is rather surprising, considering that default console codepage
> for russian cyrillic is 866).
>
> I don't have the full understanding of what's happening, but somehow
> PROMPT_COMMAND is involved.
>
> The observed effect is this:
> I have
> 1.
> PROMPT_COMMAND='printf
> "\e]0;${debian_chroot:+($debian_chroot)}${USER:-$USERNAME}@${HOSTNAME}:
> ${PWD/$HOME/\~}\a"'
> 2.
> chcp.com 65001
>
> in the .bashrc, in that order.
> When I start mintty (as login shell or as regular interactive shell), chcp
> reports CP1251.
> If I run something like
>
> $ uname -a; chcp; chcp 65001; chcp
>
> It will report that CP was changed successfully
>
> $ uname -a; chcp; chcp 65001; chcp
> CYGWIN_NT-6.1 daemon2 3.1.2(0.340/5/3) 2019-12-21 15:25 x86_64 Cygwin
> ’ҐЄгй п Є®¤®ў п бва Ёж : 1251
> Active code page: 65001
> Active code page: 65001
>
> but an immediate call to chcp afterwards reports
>
> $ chcp
> ’ҐЄгй п Є®¤®ў п бва Ёж : 1251
>
> Ooopsss??
Thanks for the report. I have found the cause in pty code.
I will submit a patch for this issue shortly.
--
Takashi Yano
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
