[PATCH 1/1] Cygwin: console: Fix the condition to interrupt select() by SIGWINCH
- Add code so that select() is not interrupted by SIGWINCH if it is
ignored (SIG_IGN or SIG_DFL).
---
winsup/cygwin/select.cc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
index 9cf892801..4e9256b9f 100644
--- a/winsup/cygwin/select.cc
+++ b/winsup/cygwin/select.cc
@@ -1045,7 +1045,9 @@ peek_console (select_record *me, bool)
else if (!PeekConsoleInputW (h, , 1, _read) || !events_read)
break;
fh->acquire_input_mutex (INFINITE);
- if (fhandler_console::input_winch == fh->process_input_message ())
+ if (fhandler_console::input_winch == fh->process_input_message ()
+ && global_sigs[SIGWINCH].sa_handler != SIG_IGN
+ && global_sigs[SIGWINCH].sa_handler != SIG_DFL)
{
set_sig_errno (EINTR);
fh->release_input_mutex ();
--
2.21.0
[PATCH 0/1] Fix select() regarding SIGWINCH in console
In cygwin test release 3.1.0-0.1, script command (from util-linux) is terminated abnormaly if the window size is changed in the case that cygwin is running in command prompt. This patch fixes this issue. This problem occurs when select() or poll() returns with EINTR by SIGWINCH even though SIGWINCH is ignored. This patch adds code so that select() is not interrupted by SIGWINCH when it is ignored (SIG_IGN or SIG_DFL). Takashi Yano (1): Cygwin: console: Fix the condition to interrupt select() by SIGWINCH winsup/cygwin/select.cc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.21.0
[PATCH 0/1] Workaround for horizontal tab on console (again)
The workaround commit 33a21904a702191cebf0e81b4deba2dfa10a406c does not work as expected if the window size is changed while screen is alternated. This patch fixes the issue. Takashi Yano (1): Cygwin: console: Fix workaround for horizontal tab position winsup/cygwin/fhandler_console.cc | 47 +++ 1 file changed, 29 insertions(+), 18 deletions(-) -- 2.21.0
[PATCH 1/1] Cygwin: console: Fix workaround for horizontal tab position
- The workaround commit 33a21904a702191cebf0e81b4deba2dfa10a406c
does not work as expected if window size is changed while screen
is alternated. Fixed.
---
winsup/cygwin/fhandler_console.cc | 47 +++
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 4afb7efb7..67638055e 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -319,6 +319,25 @@ fhandler_console::set_cursor_maybe ()
}
}
+/* Workaround for a bug of windows xterm compatible mode. */
+/* The horizontal tab positions are broken after resize. */
+static void
+fix_tab_position (HANDLE h, SHORT width)
+{
+ char buf[2048] = {0,};
+ /* Save cursor position */
+ __small_sprintf (buf+strlen (buf), "\0337");
+ /* Clear all horizontal tabs */
+ __small_sprintf (buf+strlen (buf), "\033[3g");
+ /* Set horizontal tabs */
+ for (int col=8; colkill_pgrp (SIGWINCH);
return true;
}
@@ -1615,6 +1617,12 @@ static const wchar_t __vt100_conv[31] = {
inline
bool fhandler_console::write_console (PWCHAR buf, DWORD len, DWORD& done)
{
+ bool need_fix_tab_position = false;
+ /* Check if screen will be alternated. */
+ if (wincap.has_con_24bit_colors ()
+ && memmem (buf, len*sizeof (WCHAR), L"\033[?1049", 7*sizeof (WCHAR)))
+need_fix_tab_position = true;
+
if (con.iso_2022_G1
? con.vt100_graphics_mode_G1
: con.vt100_graphics_mode_G0)
@@ -1633,6 +1641,9 @@ bool fhandler_console::write_console (PWCHAR buf, DWORD
len, DWORD& done)
len -= done;
buf += done;
}
+ /* Call fix_tab_position() if screen has been alternated. */
+ if (need_fix_tab_position)
+fix_tab_position (get_output_handle (), con.dwWinSize.X);
return true;
}
--
2.21.0
Re: SMBFS mount's file cannot be made executable
On 2019-08-14 19:40, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: >> You can often figure permissions problems > I already figured where the problem was, in how cygwin convers (or, actually > doesn't) the UNIX's "x" bit into the native DAC for the underlying filesystem > (to store as, again, "x" in the Linux share). > Missing that DACL, SMBD returns "Access denied" for an attempt to execute the > .exe file.> > I don't think that any of the requested output is of any help or indication, > rather than to actually show that the execute permission is missing. > > $ /usr/lib/csih/getVolInfo /cygdrive/z > Device Type: 7 > Characteristics: 10 > Volume Name: > Serial Number : 3112497429 > Max Filenamelength : 255 > Filesystemname : > Flags : 1006f > FILE_CASE_SENSITIVE_SEARCH : TRUE > FILE_CASE_PRESERVED_NAMES : TRUE > FILE_UNICODE_ON_DISK: TRUE > FILE_PERSISTENT_ACLS: TRUE > FILE_FILE_COMPRESSION : FALSE > FILE_VOLUME_QUOTAS : TRUE > FILE_SUPPORTS_SPARSE_FILES : TRUE > FILE_SUPPORTS_REPARSE_POINTS: FALSE > FILE_SUPPORTS_REMOTE_STORAGE: FALSE > FILE_VOLUME_IS_COMPRESSED : FALSE > FILE_SUPPORTS_OBJECT_IDS: TRUE > FILE_SUPPORTS_ENCRYPTION: FALSE > FILE_NAMED_STREAMS : FALSE > FILE_READ_ONLY_VOLUME : FALSE > FILE_SEQUENTIAL_WRITE_ONCE : FALSE > FILE_SUPPORTS_TRANSACTIONS : FALSE > > $ pwd > /cygdrive/z > > $ gcc hello.c > > $ /usr/lib/csih/getVolInfo /cygdrive/z/a.exe > Device Type: 7 > Characteristics: 10 > Volume Name: > Serial Number : 3112497429 > Max Filenamelength : 255 > Filesystemname : > Flags : 1006f > FILE_CASE_SENSITIVE_SEARCH : TRUE > FILE_CASE_PRESERVED_NAMES : TRUE > FILE_UNICODE_ON_DISK: TRUE > FILE_PERSISTENT_ACLS: TRUE > FILE_FILE_COMPRESSION : FALSE > FILE_VOLUME_QUOTAS : TRUE > FILE_SUPPORTS_SPARSE_FILES : TRUE > FILE_SUPPORTS_REPARSE_POINTS: FALSE > FILE_SUPPORTS_REMOTE_STORAGE: FALSE > FILE_VOLUME_IS_COMPRESSED : FALSE > FILE_SUPPORTS_OBJECT_IDS: TRUE > FILE_SUPPORTS_ENCRYPTION: FALSE > FILE_NAMED_STREAMS : FALSE > FILE_READ_ONLY_VOLUME : FALSE > FILE_SEQUENTIAL_WRITE_ONCE : FALSE > FILE_SUPPORTS_TRANSACTIONS : FALSE > > $ ls -dl /cygdrive/z/a.exe > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 14 21:30 /cygdrive/z/a.exe > > $ getfacl /cygdrive/z/a.exe > # file: /cygdrive/z/a.exe > # owner: lavr > # group: cppcore > user::rw- > user:lavr:rw- > group::r-- > group:cppcore:r-- > mask::rw- > other::r-- > > $ icacls `cygpath -w /cygdrive/z/a.exe` > Z:\a.exe S-1-22-1-4640:(R,W) > S-1-22-2-5333:(R) > S-1-22-2-5333:(R) > S-1-22-1-4640:(R,W) > Everyone:(R) > > Successfully processed 1 files; Failed processing 0 files Prerequisite for +x is DACL and masks allowing +x on normal file system directories and executables, as Cyggwin is emulating POSIX D/ACLs using Windows D/ACLs: drwxrwxr-x+ 1 SYSTEM SYSTEM 0 Aug 14 18:40 . # file: . # owner: SYSTEM # group: SYSTEM user::rwx user:$USER:rwx group::r-x group:Administrators:rwx group:$GROUP:r-x mask::rwx other::r-x default:user::rwx default:user:$USER:rwx default:group::--- default:group:Administrators:rwx default:mask::rwx default:other::r-x . NULL SID:(DENY)(Rc,S,REA,WEA,X,DC) NT AUTHORITY\SYSTEM:(F) $HOSTNAME\$USER:(RX,W,DC) NT AUTHORITY\SYSTEM:(RX) BUILTIN\Administrators:(RX,W,DC) BUILTIN\$GROUP:(RX) Everyone:(RX) NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,WEA,X,DC) CREATOR OWNER:(OI)(CI)(IO)(F) $HOSTNAME\$USER:(OI)(CI)(IO)(RX,W,DC) CREATOR GROUP:(OI)(CI)(IO)(Rc,S,RA) BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC) CREATOR GROUP:(OI)(CI)(IO)(DENY)(S,RD,REA,X) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files -rwxr-xr-x+ 1 $USER $GROUP 158443 Aug 3 2018 test.exe # file: test.exe # owner: $USER # group: $GROUP user::rwx group::r-x group:SYSTEM:rwx#effective:r-x group:Administrators:rwx#effective:r-x mask::r-x other::r-x test.exe NULL SID:(DENY)(Rc,S,REA,X,DC) $HOSTNAME\$USER:(F) BUILTIN\$GROUP:(RX) NT AUTHORITY\SYSTEM:(RX,W) BUILTIN\Administrators:(RX,W) Everyone:(RX) Successfully processed 1 files; Failed processing 0 files -- 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: SMBFS mount's file cannot be made executable
> This is called by acl_to_any_text, which is called by getfacl. Any > chance you could try to debug this? > I'm about to go on vacation, but I could try to help when I get back. I'm headed out of town as well. But I get this very same EINVAL for any drive (/cygdrive/X) except for the local disk C: (the only local drive my PC has): $ mount ... S: on /cygdrive/s type netapp (binary,posix=0,user,noumount,auto) ... U: on /cygdrive/u type netapp (binary,posix=0,user,noumount,auto) ... Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) ... $ getfacl /cygdrive/u # file: /cygdrive/u # owner: Unknown+User # group: Unknown+Group user::rwx user:lavr:rwx group::r-x mask::rwx other::--- getfacl: /cygdrive/u: Invalid argument $ getfacl /cygdrive/s # file: /cygdrive/s # owner: Unknown+User # group: Unknown+Group user::rwx user:lavr:rwx group::rwx mask::rwx other::--- getfacl: /cygdrive/s: Invalid argument Everything works fine for the drives U: & S: w.r.t execution. $ getfacl /cygdrive/y # file: /cygdrive/y # owner: lavr # group: cppcore user::rwx group::r-x other::r-x getfacl: /cygdrive/y: Invalid argument Drive "Y:" is a share from Linux that has special ACL flags set (I explained in previous posts): acl allow execute always = True making "everything" executable there. -- 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: SMBFS mount's file cannot be made executable
> You can often figure permissions problems I already figured where the problem was, in how cygwin convers (or, actually doesn't) the UNIX's "x" bit into the native DAC for the underlying filesystem (to store as, again, "x" in the Linux share). Missing that DAC, SMBD returns "Access denied" for an attempt to execute the .exe file. I don't think that any of the requested output is of any help or indication, rather than to actually show that the execute permission is missing. $ /usr/lib/csih/getVolInfo /cygdrive/z Device Type: 7 Characteristics: 10 Volume Name: Serial Number : 3112497429 Max Filenamelength : 255 Filesystemname : Flags : 1006f FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE $ pwd /cygdrive/z $ gcc hello.c $ /usr/lib/csih/getVolInfo /cygdrive/z/a.exe Device Type: 7 Characteristics: 10 Volume Name: Serial Number : 3112497429 Max Filenamelength : 255 Filesystemname : Flags : 1006f FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE $ ls -dl /cygdrive/z/a.exe -rw-rw-r--+ 1 lavr cppcore 157753 Aug 14 21:30 /cygdrive/z/a.exe $ getfacl /cygdrive/z/a.exe # file: /cygdrive/z/a.exe # owner: lavr # group: cppcore user::rw- user:lavr:rw- group::r-- group:cppcore:r-- mask::rw- other::r-- $ icacls `cygpath -w /cygdrive/z/a.exe` Z:\a.exe S-1-22-1-4640:(R,W) S-1-22-2-5333:(R) S-1-22-2-5333:(R) S-1-22-1-4640:(R,W) Everyone:(R) Successfully processed 1 files; Failed processing 0 files -- 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: SMBFS mount's file cannot be made executable
On 8/14/2019 4:39 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: > I also showed the "getfacl" output for that file and the directory above, > which showed > nothing additional. getfacl failed with EINVAL, as you know. So you can't rely on its output. 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
Re: SMBFS mount's file cannot be made executable
On 8/14/2019 10:07 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin
wrote:
>249 98510 [main] getfacl 3412 __set_errno: char* __acltotext(aclent_t*,
> int, const char*, char, int):1644 setting errno 22
Here's where the EINVAL is coming from. The source is in sec_acl.cc:
char *
__acltotext (...)
{
if (!aclbufp || aclcnt < 0 || aclcnt > MAX_ACL_ENTRIES
|| (aclcnt > 0 && aclsort32 (aclcnt, 0, aclbufp)))
{
set_errno (EINVAL);
return NULL;
}
This is called by acl_to_any_text, which is called by getfacl. Any
chance you could try to debug this?
I'm about to go on vacation, but I could try to help when I get back.
Ken
Re: SMBFS mount's file cannot be made executable
On 2019-08-14 05:22, Ken Brown wrote: > On 8/14/2019 12:23 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: >>> Have you checked the default ACL on the directory containing the file? >> >> No, and there's nothing special there now that I checked. I can change the >> "Read & Execute" for the .exe file from the Windows file properties without >> having to deal with anything special or additional (like inherited >> permissions), so I don't think the containing directory has anything to do >> with it.> > I suspect the containing directory has a lot to do with it. You shouldn't > get an "Invalid argument" error below. > >> $ getfacl /cygdrive/z >> # file: /cygdrive/z >> # owner: lavr >> # group: cppcore >> user::rwx >> group::r-x >> other::r-x >> getfacl: /cygdrive/z: Invalid argument > > Running getfacl under strace might provide a clue as to what the problem is. > You could also try running /usr/lib/csih/getVolInfo.exe on that directory. Running getVolInfo shows you supported operations and options: $ /usr/lib/csih/getVolInfo "$exe" Device Type: 7 Characteristics: 20020 Volume Name: Serial Number : 112776248 Max Filenamelength : 255 Filesystemname : Flags : 3e706ff FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : TRUE You can often figure permissions problems out yourself by looking at the outputs from: $ ls --color=auto -dl "$exe" $ getfacl "$exe" $ icacls "$(cygpath -m ""$exe"")" and correlating the info, perhaps also with the same commands executed on the containing directory. If you post those output from your system, other may be able to help you. To first approximations: all file access problems are permissions problems; and all programming problems are application programmer array access problems. ;^> You have to first totally eliminate all possibilities of those, before you should bother looking at other prossible causes. -- 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: Was CygLSA removed?
On Wed, 2019-08-14 at 23:22 +0300, Andrey Repin wrote: > I've apparently missed something, but I can't seems to find CygLSA64.dll in > recent cygwin packages. > Was it deprecated/removed? Yes: https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=0fb497165f8545470624012315aeaf37333c1ea2;hp=84230b71c64765ad0e34faffdfe6d1c58477a84d https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=2741dd055010546c25223e6a4d0dc6aedc4b6607;hp=3b21333172e57f56fa44ce63a10c368289701062 -- Yaakov -- 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: SMBFS mount's file cannot be made executable
> See the '+' at the end of the modes? I saw that, and I also showed the "getfacl" output for that file and the directory above, which showed nothing additional. > Maybe, but we'd still need to know how to get to the result you're seeing. Just take a samba server (4.x) and mount a share with default settings on your Windows box; then try to change the execute permissions for files in there from Cygwin's shell, using chmod -- the simplest. > I hope it's clear to you that the permissions you see on this tab have > nothing to do with the POSIX mode bits you're trying to set from Cygwin. That is completely untrue; the underlying filesystem is still controlled by the OS (Windows) in either case. When the "x" permission is set from under Cygwin, it has to get converted (inside the Cygwin dll) to an appropriate DAC for the native file system layer. That DAC is then sent to the samba server (in case of the smb filesystem), which then either converts it back to the "x" permission (when the SMBD is on Linux) or stores it on the target filesystem, if that's a Windows box. And it works the similar way in the reverse: when a file stat is requested from Cygwin, the SMBD gets the "x" bit, converts it to SMB response (native for Windows DAC for "execute") and sends it back to Windows box, which is then read by Cygwin DLL and gets shown as "x" bit in the POSIX mode. When I just use the file properties dialog, I bypass only one step in the chains I just described, Cygwin DLL. And it works by setting the "x" bit on the server side (Linux). So, that's how I know that something's off in how Cygwin treats that "x" permission when asked to set it on a file. When Windows is about to run an .exe file, it consults the filesystem whether the execute DAC is set. In case of SMBD 4.x, the filesystem will respond "Access denied" if the "x" permission is not found. It used to say "okay" in the previous versions. I quoted the report: https://forge.univention.org/bugzilla/show_bug.cgi?id=33785 So when I asked my Systems guys that the share to be exported with acl allow execute always = True I can now execute any files (even those whose "x" bits are not set at all! -- SMBD clears everything to execute, which is madness). Well, that works around the issue for me, but the question remains as to why when "chmod +x" is given, Cygwin does not cause the "x" permission to be set on the target file if that file resides on smbfs. I suspect there are no provisions in code to do that, but I may be wrong. -- 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
Was CygLSA removed?
Greetings, All! I've apparently missed something, but I can't seems to find CygLSA64.dll in recent cygwin packages. Was it deprecated/removed? -- With best regards, Andrey Repin Wednesday, August 14, 2019 23:09: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
Re: getpriority() and top display for priority inconsistent
> Feel free to provide a patch, just, please, create a valid git commit message
"getpriority() consistent with process priority
https://cygwin.com/ml/cygwin/2019-08/msg00122.html;
The changeset is really trivial:
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index a914ae8..20126ce 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -3977,7 +3977,12 @@ getpriority (int which, id_t who)
if (!who)
who = myself->pid;
if ((pid_t) who == myself->pid)
- return myself->nice;
+{
+ DWORD winprio = GetPriorityClass(GetCurrentProcess());
+ if (winprio != nice_to_winprio(myself->nice))
+myself->nice = winprio_to_nice(winprio);
+ return myself->nice;
+}
break;
case PRIO_PGRP:
if (!who)
--
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: SMBFS mount's file cannot be made executable
Greetings, Lavrentiev, Anton (NIH/NLM/NCBI) [C]! >> What is your cygdrive mount options? Because default is, apparently, >> "binary,posix=0,user". > I have no idea where they are kept at, and how to change them. This is, as I said, the DEFAULT. To change them, edit /etc/fstab, add the desired line. F.e. none /cygdrive cygdrive binary,posix=0,nouser 0 0 > Also, I couldn't make this work, anyways; yet I thought it should have worked: >> > $ mount -o exec //coredev2/home/lavr /mnt >> > $ mount >> > //coredev2/home/lavr on /mnt type smbfs (binary,exec,user) >> > ... >> > $ cd /mnt >> > $ pwd >> > /mnt >> > $ gcc a.c >> > $ ls -l a.exe >> > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 13 08:20 a.exe >> > $ ./a.exe >> > -bash: ./a.exe: Permission denied -- With best regards, Andrey Repin Wednesday, August 14, 2019 22:50:18 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Wed, 14 Aug 2019 15:49:00 +0200
Corinna Vinschen wrote:
> The only reason I can see is if sigwait_common() returns EINTR because
> it was interrupted by an unrelated signal. This in turn lets the read()
> call fail with EINTR and that should be expected by the callers, in
> theory.
Strangely, this problem also disappears with this patch.
diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
index 9cf892801..82ac0674f 100644
--- a/winsup/cygwin/select.cc
+++ b/winsup/cygwin/select.cc
@@ -1869,7 +1869,7 @@ thread_signalfd (void *arg)
switch (WaitForSingleObject (si->evt, INFINITE))
{
case WAIT_OBJECT_0:
- tls->signalfd_select_wait = NULL;
+ //tls->signalfd_select_wait = NULL;
event = true;
break;
default:
Moreover, this EINTR is not set by sigwait_common() but set by
select_stuff::wait().
With following debug print, the message shows:
1 [main] script 1082 select_stuff::wait: signal = 20
script: poll failed: Interrupted system call
Script done, file is typescript
however, the signal 20 (SIGCHLD) is registered to signalfd by
script and should be caught.
diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
index 9cf892801..adcc75ad3 100644
--- a/winsup/cygwin/select.cc
+++ b/winsup/cygwin/select.cc
@@ -446,6 +446,7 @@ next_while:;
unconditionally, ignoring any SA_RESTART detection by
call_signal_handler(). */
_my_tls.call_signal_handler ();
+ system_printf ("signal = %d\n", _my_tls.infodata.si_signo);
set_sig_errno (EINTR);
res = select_signalled; /* Cause loop exit in cygwin_select */
break;
--
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: Hung setup-x86_64.exe after parsing setup.ini
Веснин Юрий Александрович writes: > It's definitely a bug. What's the proper way to fix it? It's not a fix, but for starters you could create a bunch of smaller packages. > Addition: > @ rdc-deps > sdesc: "RDC's devel dependencies" > ldesc: "RDC's devel dependencies" > category: Base > requires: ca-certificates gcc-core gcc-g++ git gnupg libftdi1 lynx make > openssh python python27 python27-pip python38 python38-pip subversion vim wget > version: 0.1-1 > install: x86_64/release/rdc-deps/rdc-deps-0.1-1.tar.xz 10240 > 2aaf7929c7d5299e2613f5a9eb18d7a644c81d0da7a6fba93069c83a490ec798941043a8ed8bb95b28ce21179e987e1f04f372a891a5918b40db6f612276f6e4 > source: x86_64/release/rdc-deps/rdc-deps-0.1-1-src.tar.xz 108 > da016ecd9ac6dd3ecd1a65b80c2728db59bccd9ca5e6b54888f02398e3f97a90d1bae3bef85f0eb0950c07734bf3e191fb679fc39527205ba0520009ca4769d2 > depends2: ca-certificates, gcc-core, gcc-g++, git, gnupg, libftdi1, lynx, > make, openssh, python, python27, python27-pip, python38, python38-pip, > subversion, vim, wget > > @ rdc-tools > sdesc: "RDC's toolchain" > ldesc: "RDC's toolchain" > category: Base > requires: rdc-deps > version: 1.1.1-1 > install: x86_64/release/rdc-tools/rdc-tools-1.1.1-1.tar.xz 1378576256 > 5b15397950db4f95e3e0560a5c9183b3811e821cfb183db1bf93a411e01e5bb4b86825a28f8121389422ffd7e9f12eef88b22560f8c30b2beb5fae230c738332 > source: x86_64/release/rdc-tools/rdc-tools-1.1.1-1-src.tar.xz 108 > da016ecd9ac6dd3ecd1a65b80c2728db59bccd9ca5e6b54888f02398e3f97a90d1bae3bef85f0eb0950c07734bf3e191fb679fc39527205ba0520009ca4769d2 > depends2: rdc-deps None of this should have category Base. Use your own category and install by category in setup.exe. I hope it's obvious that the empty rdc-deps package is currently useless and you could just list the deps right here. But you could depend on non-empty pakcages of your own and therefore split this hguhe thing into a number of packages that have more manageable sizes. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: SMBFS mount's file cannot be made executable
Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin writes: >> If it's related to the ACL handling then it should start working when >> you remove the ACL on the file with 'setfacl -kb ...' > > There are no special ACLs set on the file (that was just produced by > GCC from the source code, see my first email). You earlier showed this: > $ ls -l a.exe > -rw-rw-r--+ 1 lavr cppcore 157753 Aug 13 08:20 a.exe See the '+' at the end of the modes? That's telling you that there is an ACL added to the file and the modes are the result of combining thje actual mode bits with the ACL. As you said, gcc won't add any ACL by itself, so these ACL are the result of inheritable / default ACL. > But I am now convinced that the problem is _entirely_ in Cygwin's corner: Maybe, but we'd still need to know how to get to the result you're seeing. > When I open that file's the "Properties->Security" Windows tab, I can > see that my permissions are "Read" and "Write", yet "Read & Execute" > is NOT checked. When I check it, I see that the file becomes > executable (the "x" bit) from both Cygwin shell and on the Linux side, > too. And after that, I can execute the file from the Cygwin shell. I hope it's clear to you that the permissions you see on this tab have nothing to do with the POSIX mode bits you're trying to set from Cygwin. > So what happens is that when "chmod" (or "creat" with a permission > mask) is called, Cygwin does not honor the "x" bit(s) and does not > convert it to a corresponding proper ACL for the Windows mounted > filesystem (and that ACL, in turn, would have been then sent to SMBD > to get converted there back to the "x" bit in the Unix world). Once > the "x" is there, Windows(via SMBD) obviously allows execution of the > image. Here's a related "bug": Most often that is the result of an inherited ACL mask that clears that bit. Correcting either the default ACL or removing it should then make that problem go away. Default ACL are associated with the parent directory and you're unlikely to be able to change the parent directory modes if it's the root of a file system exported from a filer. Try again in a subdirectory and clear the default ACL with 'setfacl -kb' on that directory before you start doing anything there. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: SMBFS mount's file cannot be made executable
> I suspect the containing directory has a lot to do with it. Please elaborate what you ground your suspicion on. Like I said previously, I can add "Read & Execute" permissions to the file in question from the Windows file properties dialog, and it gets converted to an "x" on Linux side, then the file becomes executable from on Windows (from either within a Cygwin shell or outside). AFAICT, there's nothing in strace (follows) rather than trying to get info on "Z:" twice. $ strace getfacl /cygdrive/z --- Process 3412 created --- Process 3412 loaded C:\Windows\System32\ntdll.dll at 7ffcdea7 --- Process 3412 loaded C:\Windows\System32\kernel32.dll at 7ffcdde6 --- Process 3412 loaded C:\Windows\System32\KernelBase.dll at 7ffcdbbe --- Process 3412 thread 2912 created --- Process 3412 loaded C:\Cygwin64\bin\cygwin1.dll at 00018004 2 2 [main] getfacl (3412) ** 48 50 [main] getfacl (3412) Program name: C:\Cygwin64\bin\getfacl.exe (windows pid 3412) 25 75 [main] getfacl (3412) OS version: Windows NT-10.0 23 98 [main] getfacl (3412) ** --- Process 3412 loaded C:\Windows\System32\advapi32.dll at 7ffcde99 --- Process 3412 loaded C:\Windows\System32\msvcrt.dll at 7ffcddd2 --- Process 3412 loaded C:\Windows\System32\sechost.dll at 7ffcdd80 --- Process 3412 loaded C:\Windows\System32\rpcrt4.dll at 7ffcde80 --- Process 3412 thread 2120 created --- Process 3412 loaded C:\Windows\System32\cryptbase.dll at 7ffcda7d --- Process 3412 loaded C:\Windows\System32\bcryptprimitives.dll at 7ffcdbe6 37323830 [main] getfacl (3412) sigprocmask: 0 = sigprocmask (0, 0x0, 0x1802FBC50) 6304460 [main] getfacl 3412 open_shared: name shared.5, n 5, shared 0x18003 (wanted 0x18003), h 0xC8, *m 6 1934653 [main] getfacl 3412 user_heap_info::init: heap base 0x6, heap top 0x6, heap size 0x2000 (536870912) 2274880 [main] getfacl 3412 open_shared: name S-1-5-21-2137354491-1741569864-122644288-1606.1, n 1, shared 0x18002 (wanted 0x18002), h 0xC4, *m 6 1625042 [main] getfacl 3412 user_info::create: opening user shared for 'S-1-5-21-2137354491-1741569864-122644288-1606' at 0x18002 2455287 [main] getfacl 3412 user_info::create: user shared version AB1FCCE8 1785465 [main] getfacl 3412 fhandler_pipe::create: name \\.\pipe\cygwin-e022582115c10879-3412-sigwait, size 11440, mode PIPE_TYPE_MESSAGE 555520 [main] getfacl 3412 fhandler_pipe::create: pipe read handle 0xDC 245544 [main] getfacl 3412 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-e022582115c10879-3412-sigwait 1185662 [main] getfacl 3412 fhandler_pipe::create: pipe write handle 0xE0 1955857 [main] getfacl 3412 dll_crt0_0: finished dll_crt0_0 initialization --- Process 3412 thread 20940 created 9326789 [main] getfacl 3412 time: 1565789069 = time(0x0) 296818 [sig] getfacl 3412 wait_sig: entering ReadFile loop, my_readsig 0xDC, my_sendsig 0xE0 1556973 [main] getfacl 3412 mount_info::conv_to_posix_path: conv_to_posix_path (\\coredev2\home\lavr, 0x0, no-add-slash) 2087181 [main] getfacl 3412 normalize_win32_path: \\coredev2\home\lavr = normalize_win32_path (\\coredev2\home\lavr) 1167297 [main] getfacl 3412 mount_info::conv_to_posix_path: /mnt = conv_to_posix_path (\\coredev2\home\lavr) 1677464 [main] getfacl 3412 sigprocmask: 0 = sigprocmask (0, 0x0, 0x600018130) 3187782 [main] getfacl 3412 _cygwin_istext_for_stdio: fd 0: not open 1097891 [main] getfacl 3412 _cygwin_istext_for_stdio: fd 1: not open 1188009 [main] getfacl 3412 _cygwin_istext_for_stdio: fd 2: not open 3688377 [main] getfacl (3412) open_shared: name cygpid.3412, n 3412, shared 0x18001 (wanted 0x18001), h 0x108, *m 2 1888565 [main] getfacl (3412) time: 1565789069 = time(0x0) 1508715 [main] getfacl 3412 pinfo::thisproc: myself dwProcessId 3412 1228837 [main] getfacl 3412 environ_init: GetEnvironmentStrings returned 0x113B10 6269463 [main] getfacl 3412 win32env_to_cygenv: 0x6000284F0: ADVISOR_2018_DIR=C:\Program Files (x86)\IntelSWTools\Advisor 2018\ 809543 [main] getfacl 3412 win32env_to_cygenv: 0x600028540: ADVISOR_2019_DIR=C:\Program Files (x86)\IntelSWTools\Advisor 2019\ 1119654 [main] getfacl 3412 win32env_to_cygenv: 0x600028590: ALLUSERSPROFILE=C:\ProgramData 1949848 [main] getfacl 3412 win32env_to_cygenv: 0x6000285C0: APPDATA=C:\Users\lavr\AppData\Roaming 170 10018 [main] getfacl 3412 win32env_to_cygenv: 0x6000285F0: BLASTDB=\\snowman\blast\db\blast 234 10252 [main] getfacl 3412 win32env_to_cygenv: 0x600028620: COMMONPROGRAMFILES=C:\Program Files\Common Files 322 10574 [main] getfacl 3412 win32env_to_cygenv: 0x600028660: COMPUTERNAME=NCBIPC9135 71 10645 [main]
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Aug 14 20:47, Takashi Yano wrote: > On Wed, 14 Aug 2019 20:41:00 +0900 > Takashi Yano wrote: > > Hi Corinna, > > > > On Tue, 13 Aug 2019 12:47:53 +0200 > > Corinna Vinschen wrote: > > > I created a patch which *seems* to do the right thing. I'm not > > > yet sure it's the best solution, but it seems to do the trick, at > > > least. > > > > > > I'm just creating new developer snapshots, please try. I'll > > > create another test release later this week. > > > > I confirmed the STC works as expected. Thank you. > > > > However, it seems that signalfd still has a problem. > > > > If script command (from util-linux) is terminated by '^D', > > the following error message is sometimes shown. > > > > script: poll failed: Interrupted system call > > > > I have confirmed this in 32bit cygwin with bash as login shell. > > This rarely occurs in real machine, however, often occurs in > > virtual machine in VirtualBox. > > Sorry, I forgot to mention important thing. > > This occurs only in cygwin on command prompt. Not in mintty. The only reason I can see is if sigwait_common() returns EINTR because it was interrupted by an unrelated signal. This in turn lets the read() call fail with EINTR and that should be expected by the callers, in theory. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Wed, 14 Aug 2019 20:41:00 +0900 Takashi Yano wrote: > Hi Corinna, > > On Tue, 13 Aug 2019 12:47:53 +0200 > Corinna Vinschen wrote: > > I created a patch which *seems* to do the right thing. I'm not > > yet sure it's the best solution, but it seems to do the trick, at > > least. > > > > I'm just creating new developer snapshots, please try. I'll > > create another test release later this week. > > I confirmed the STC works as expected. Thank you. > > However, it seems that signalfd still has a problem. > > If script command (from util-linux) is terminated by '^D', > the following error message is sometimes shown. > > script: poll failed: Interrupted system call > > I have confirmed this in 32bit cygwin with bash as login shell. > This rarely occurs in real machine, however, often occurs in > virtual machine in VirtualBox. Sorry, I forgot to mention important thing. This occurs only in cygwin on command prompt. Not in mintty. -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
Hi Corinna, On Tue, 13 Aug 2019 12:47:53 +0200 Corinna Vinschen wrote: > I created a patch which *seems* to do the right thing. I'm not > yet sure it's the best solution, but it seems to do the trick, at > least. > > I'm just creating new developer snapshots, please try. I'll > create another test release later this week. I confirmed the STC works as expected. Thank you. However, it seems that signalfd still has a problem. If script command (from util-linux) is terminated by '^D', the following error message is sometimes shown. script: poll failed: Interrupted system call I have confirmed this in 32bit cygwin with bash as login shell. This rarely occurs in real machine, however, often occurs in virtual machine in VirtualBox. -- 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: SMBFS mount's file cannot be made executable
On 8/14/2019 12:23 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote: >> Have you checked the default ACL on the directory containing the file? > > No, and there's nothing special there now that I checked. I can change the > "Read & Execute" for the .exe file from the Windows file properties > without having to deal with anything special or additional (like inherited > permissions), so I don't think the containing directory has anything > to do with it. I suspect the containing directory has a lot to do with it. You shouldn't get an "Invalid argument" error below. > $ getfacl /cygdrive/z > # file: /cygdrive/z > # owner: lavr > # group: cppcore > user::rwx > group::r-x > other::r-x > getfacl: /cygdrive/z: Invalid argument Running getfacl under strace might provide a clue as to what the problem is. You could also try running /usr/lib/csih/getVolInfo.exe on that directory. Ken
Re: Hung setup-x86_64.exe after parsing setup.ini
>>> If you provide more details on that problem, I can probably give some >>> advice. >> >> I suppose that bug comes from parsing setup.ini because of cygwin hangs on >> such stage. >> You can find more details by following previously described steps. > You wrote: "We started to investigate setup.exe sources but we stuck in > bison sources." > I have no idea what kind of problem you encountered trying to > investigate the problem. Unless you provide more details about what you > got stuck on, I can't help you very much. Okay. The problem happens when we trying to add the large package with size around 1378576256 bytes parsing setup.ini. This freeze at the installation process. -- 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: [ANNOUNCEMENT] TEST: Cygwin 3.1.0-0.1
On Tue, 13 Aug 2019 23:50:54 +0200 Thorsten Kampe wrote: > > I compiled tree > > (http://mama.indstate.edu/users/ice/tree/src/tree-1.8.0.tgz). > > > > Mintty: 2.5s > > Cmd: 122s > > > > Make clean[1]: > > Mintty: 0.3s > > Cmd: 60,3s > > A second compile took even three minutes: > real3m1,822s > user0m1,158s > sys 0m0,751s > > The times in Mintty: > real0m2,281s > user0m1,006s > sys 0m0,844s I cannot reproduce this. [In command prompt] yano@Express5800-S70 ~/tree/tree-1.8.0 $ time make gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o tree.o tree.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o unix.o unix.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o html.o html.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o xml.o xml.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o json.o json.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o hash.o hash.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o color.o color.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o file.o file.c gcc -o tree tree.o unix.o html.o xml.o json.o hash.o color.o file.o real0m2.240s user0m0.943s sys 0m1.186s yano@Express5800-S70 ~/tree/tree-1.8.0 $ time make clean if [ -x tree ]; then rm tree; fi if [ -f tree.o ]; then rm *.o; fi rm -f *~ real0m0.241s user0m0.030s sys 0m0.261s [In mintty] yano@Express5800-S70 ~/tree/tree-1.8.0 $ time make gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o tree.o tree.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o unix.o unix.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o html.o html.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o xml.o xml.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o json.o json.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o hash.o hash.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o color.o color.c gcc -ggdb -pedantic -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -c -o file.o file.c gcc -o tree tree.o unix.o html.o xml.o json.o hash.o color.o file.o real0m2.264s user0m1.130s sys 0m1.059s yano@Express5800-S70 ~/tree/tree-1.8.0 $ time make clean if [ -x tree ]; then rm tree; fi if [ -f tree.o ]; then rm *.o; fi rm -f *~ real0m0.229s user0m0.015s sys 0m0.199s The results are almost same. -- 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
