src/winsup/doc ChangeLog ntsec.xml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-24 10:35:31 Modified files: winsup/doc : ChangeLog ntsec.xml Log message: * ntsec.xml: More language and typo fixes. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.499r2=1.500 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ntsec.xml.diff?cvsroot=srcr1=1.7r2=1.8
src/winsup/cygwin ChangeLog gendef
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-24 13:40:03 Modified files: winsup/cygwin : ChangeLog gendef Log message: * gendef (sigdelayed): 64 bit only: Push CPU flags before aligning stack to avoid changing flag values. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6550r2=1.6551 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/gendef.diff?cvsroot=srcr1=1.56r2=1.57
src/winsup/cygwin ChangeLog gendef
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-24 15:04:11 Modified files: winsup/cygwin : ChangeLog gendef Log message: * gendef (sigdelayed): 64 bit only: Fix seh_pushreg statements in prologue. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6551r2=1.6552 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/gendef.diff?cvsroot=srcr1=1.57r2=1.58
src/winsup/doc ntsec.xml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-24 16:44:38 Modified files: winsup/doc : ntsec.xml Log message: fix typo Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ntsec.xml.diff?cvsroot=srcr1=1.8r2=1.9
src/winsup/cygwin ChangeLog fhandler_proc.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-24 19:08:56 Modified files: winsup/cygwin : ChangeLog fhandler_proc.cc Log message: * fhandler_proc.cc (format_proc_cygdrive): Fix symlink path if cygdrive is /. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6552r2=1.6553 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_proc.cc.diff?cvsroot=srcr1=1.124r2=1.125
src/winsup/doc new-features.xml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-24 19:14:49 Modified files: winsup/doc : new-features.xml Log message: Fix typo Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/new-features.xml.diff?cvsroot=srcr1=1.29r2=1.30
src/winsup/cygwin/release 1.7.33
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-10-24 19:16:11 Modified files: winsup/cygwin/release: 1.7.33 Log message: Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/release/1.7.33.diff?cvsroot=srcr1=1.10r2=1.11
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On 24/10/14 02:43, Corinna Vinschen wrote: On Oct 22 20:57, Tom Schutter wrote: On Wed 2014-10-22 11:23, Corinna Vinschen wrote: For your convenience I wrote new documentation. Since this is a TEST prerelease, the new documentation is not part of the official docs yet. Rather have a look at https://cygwin.com/preliminary-ntsec.html machine is no domain member - machine is not a domain member Thanks, I applied this as patch. Corinna Obviously, all the URLs for the section called “Mapping Windows accounts to POSIX accounts” will become correct when the file is renamed from preliminary-ntsec.html to ntsec.html. But in the section where you talk about the 'problem with the definition of a correct ACL which disallows mapping of certain POSIX permissions cleanly', previously the URL referenced immediately after that text appeared as 'the section called The POSIX permission mapping leak ', but now it's yet another reference to 'the section called “Mapping Windows accounts to POSIX accounts”' -- Is that a mistake? Other suggestions/notes: 'One of them is that the idea to have always small files is flawed.' -- 'One of them is that the idea that these files will always be small, is flawed.' 'so we rely on some mechanism to convert SIDs to uid/gid values and vice versa' -- 'so we need a mechanism to convert SIDs to uid/gid values and vice versa' 'It allows [us] to generate uid/gid values ' 'Read /etc/passwd and /etc/group files [if they exist], just as in the olden days' 'If [the passwd or group] files are present, they will be scanned on demand' 'Logon SIDs: The own[huh? owner's? user's?] LogonSid is converted' 'if the AD administrators chose an unreasonable[unreasonably] small' 'which keeps an analogue value of the trustPosixOffset' -- 'which keeps an analog of the trustPosixOffset' 'how do we uniquely differ[distinguish] between them by name?' 'very costly (read: slow) sea[r]ch operations' (By the way, if you want to belong to multiple groups, is the only way to do this via an /etc/group file? Also, it occurs to me that another way to store the unix home dir, etc., would be a 'partial passwd' file that omitted the fields for the parts supplied easily by AD (SID, GID)? That's just an idle thought.) 'Cygwin process tree, which[ever?] first process' 'is not running a[t] the time' 'via an undocumented API[,] an applications[application] can fetch' 'When Cygwin stat's[stats, or: stat()s] files' 'If both[,] files and db are specified' 'Cygwin will always try the files first, then the db. ' -- is that because the db will always be more trustworthy than the files? BTW, the POSIX permission mapping leak used to have a section heading; it's now just unmarked, inside the File Permissions section. (I'm just pointing that out.) Hope this helps! You've obviously put a lot of thought and effort into all this: thanks. luke -- 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: Setup 2.774 texlive postinstall takes 10+ hours
I wouldn't try to restart the install without figuring out why /etc/postinstall/texlive-collection-basic.sh didn't complete. Is there anything at all in /var/log/ that might provide a clue? Usually setup writes temporary files while it's executing postinstall scripts. There wasn't even a /var/log directory until the install was finished. What I finally did to get it to finish was to move all the texlive-collection files out of the postinstall directory and the install process finished all the rest quite rapidly. Then I put them back, except for the language packages, and reran the install program and one by one moved the files back out again if they stalled. In the end there were 8 that wouldn't run. In the temporary logs are a lot of error messages similar to the following three: Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. 7 [main] perl 8088 child_info_fork::abort: unable to remap Fcntl.dll to same address as parent (0x2E) - try running rebaseall Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. 6 [main] perl 8056 child_info_fork::abort: address space needed by 'MD5.dll' (0x2D) is already occupied Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. 5 [main] perl 8076 child_info_fork::abort: address space needed by 'IO.dll' (0x2F) is already occupied I looked for updmap but there doesn't appear to be even a /usr/bin directory, so I must be looking in the wrong place. In any case, I did get the install to complete by this rather ugly method except for those 8 packages and all the language files. I don't know if this method will have fouled up anything else or not. If the log files would be of any value to you, I've put them here: http://www.macdougalls.net/cygwinlogs/ Thanks for your help, Don -- View this message in context: http://cygwin.1069669.n5.nabble.com/Setup-2-774-texlive-postinstall-takes-10-hours-resending-due-to-cygwin-bounce-tp92260p112141.html Sent from the Cygwin list mailing list archive at Nabble.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: Threads
On Oct 23 21:07, Ken Brown wrote: On 10/23/2014 4:32 PM, Ken Brown wrote: On 10/23/2014 11:37 AM, Corinna Vinschen wrote: On Oct 23 08:04, Ken Brown wrote: On 10/23/2014 7:31 AM, Jon TURNEY wrote: On 20/10/2014 14:03, Ken Brown wrote: Or is there some other plausible explanation for impossible crashes? This can't just be a result of a gdb bug, because in at least one case the assertion can be shown to be valid by using printf instead of gdb. [*] By impossible I mean that examination of the relevant variables in gdb shows that the assertions are in fact true. Two ongoing examples are http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18438 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18769 As a suggestion, you might want to also take a careful look at how signal delivery is implemented in cygwin on x86_64 I had a vague idea that there was, at some time in the past, a fix made for register corruption on x86_64 after a signal was handled, but I can't find it now, so maybe I imagined it. Is this what you're thinking of? https://cygwin.com/ml/cygwin-cvs/2014-q1/msg00020.html But if for e.g. the flags register was getting corrupted when a signal interrupts the main thread, that could perhaps also explain what is being seen. Yes, flags register corruption is exactly what Eli suggested in the other bug report I cited. The aforementioned patch was supposed to fix this problem and it is definitely in the current 1.7.32 release... The ChangeLog entry just mentions the FPU control word and the XMM registers, but not the ordinary FLAGS register (or rather EFLAGS for x86 and RFLAGS for x86_64, if I'm understanding correctly what I find in Wikipedia). Did the patch also take care of that? Never mind, it looks like that was already OK before the patch. I see that there are pushf and popf instructions in gendef. Right. If there's any indication that this isn't sufficient, please tell me. Maybe there's some other kind of CPU state information which needs to be saved and restored for signal handling?!? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpl9He6kfdGA.pgp Description: PGP signature
Re: Problems on case-sensitive file systems
On Oct 23 19:21, Thomas Wolff wrote: Am 23.10.2014 17:36, schrieb Corinna Vinschen: On Oct 23 14:42, Thomas Wolff wrote: Am 22.10.2014 16:00, schrieb Corinna Vinschen: On Oct 22 09:01, Thomas Wolff wrote: I'm facing a number of issues with case-sensitivity which I've collected: There is a documented limitation on case-sensitivity using drive letter paths, also mentioned in https://sourceware.org/ml/cygwin/2013-08/msg00090.html (last item). I vaguely remember seeing a reason for this limitation in some mail but can't find it again. I think it would be good to remove this limitation because it breaks user expectations when working on case-sensitive drives. The user expectation when using DOS paths is caseinsensitivity in the first place. But, as usual, there's no way to do this right, since somebody will have another POV. My stance is, don't use DOS paths when using Cygwin. At leats don't use DOS paths if you have any expectations about special POSIX path handling on Cygwin. I use an application that uses Windows or mixed paths, I cannot influence it. So while I understand your POV, it would still be helpful to have path interpretation fully-featured. (If you point me to a place in winsup, I might even try to do something myself.) I'm not going to apply a patch to do that. DOS paths get no special treatment, they are always handled with DOS/Windows defaults. Any last chance to get a distinction here between X:\dos\paths and X:/mixed/paths? As Andrey already wrote, it's pretty much the same thing. As soon as you're using DOS paths (and drive letter paths with slashes are still DOS paths), the assumption is that the application expects DOS semantics. I have now this in /etc/fstab: C: /mnt/c ntfs binary,nouser,posix=1,noumount 0 0 T: /mnt/t smbfs binary,user,posix=1,noumount,auto 0 0 Drop the noumount and it will work. noumount is an unknown mount flag and, FWIW, not documented in https://cygwin.com/cygwin-ug-net/using.html#mount-table Ah! Thanks. That reminds me of that other problem I had previously observed but forgotten: mount does not report option errors... Right. Mount doesn't know the valid options by itself. It gets a list by calling into the Cygwin DLL. The fact that mount doesn't check them and report unknown options is a bit awkward. Patches welcome. Also: mount suggests this problem itself by reporting that very unknown option when running just 'mount' Uh, yes. This is the option historically printed for cygdrive mount points. It's not a valid option for fstab, though. And as a last, minor issue: mount does not work on relative paths (like it does on Unix/Linux) but needs an absolute path: mount /mnt/c # works cd /mnt; mount c # does not work This is historical, too. There never has gone much work into mount since it was most of the time good enough. If you want to get relative pathname support for the POSIX side of mount points, feel free to hack away. It's a neat feature. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpssaXQlR82a.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On Oct 23 20:01, Achim Gratz wrote: Achim Gratz writes: Corinna Vinschen writes: In theory, no. The last OpenSSH update, 6.7p1-1, alreadyd contained the upstream fix to work with local sshd accounts which have the machine name prepended. I will check this tomorrow, I somehow missed that this patch was live. The entry for sshd was the only thing still in my servers' /etc/passwd. I can confirm that with this OpenSSH version I don't need the workaround via /etc/passwd anymore. Thanks for testing this feature! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpr2fVaoaaiz.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On Oct 24 17:35, Luke Kendall wrote: On 24/10/14 02:43, Corinna Vinschen wrote: On Oct 22 20:57, Tom Schutter wrote: On Wed 2014-10-22 11:23, Corinna Vinschen wrote: For your convenience I wrote new documentation. Since this is a TEST prerelease, the new documentation is not part of the official docs yet. Rather have a look at https://cygwin.com/preliminary-ntsec.html machine is no domain member - machine is not a domain member Thanks, I applied this as patch. Corinna Obviously, all the URLs for the section called “Mapping Windows accounts to POSIX accounts” will become correct when the file is renamed from preliminary-ntsec.html to ntsec.html. But in the section where you talk about the 'problem with the definition of a correct ACL which disallows mapping of certain POSIX permissions cleanly', previously the URL referenced immediately after that text appeared as 'the section called The POSIX permission mapping leak ', but now it's yet another reference to 'the section called “Mapping Windows accounts to POSIX accounts”' -- Is that a mistake? Yes, it is. Thanks for catching. It should point to the chapter File permissions. Other suggestions/notes: 'One of them is that the idea to have always small files is flawed.' -- 'One of them is that the idea that these files will always be small, is flawed.' 'so we rely on some mechanism to convert SIDs to uid/gid values and vice versa' -- 'so we need a mechanism to convert SIDs to uid/gid values and vice versa' 'It allows [us] to generate uid/gid values ' 'Read /etc/passwd and /etc/group files [if they exist], just as in the olden days' 'If [the passwd or group] files are present, they will be scanned on demand' 'Logon SIDs: The own[huh? owner's? user's?] LogonSid is converted' The logon SID of the current session. I rephrased this now to: Logon SIDs: The LogonSid of the current user's session is converted ... 'if the AD administrators chose an unreasonable[unreasonably] small' 'which keeps an analogue value of the trustPosixOffset' -- 'which keeps an analog of the trustPosixOffset' British vs. American English... ;) 'how do we uniquely differ[distinguish] between them by name?' 'very costly (read: slow) sea[r]ch operations' (By the way, if you want to belong to multiple groups, is the only way to do this via an /etc/group file? You mean via the gr_mem field? That's not evaluated anymore. Group membership is stored in SAM or AD. Also, it occurs to me that another way to store the unix home dir, etc., would be a 'partial passwd' file that omitted the fields for the parts supplied easily by AD (SID, GID)? That's just an idle thought.) But that means you have to read the files again. Thre's not much of an advantage to having full passwd and group files then for the user, nor for Cygwin itself. Plus, you have to implement two different reading algos per file type. 'Cygwin process tree, which[ever?] first process' Hmm. Sounds bad, right? What I'm trying to say is, if the first process of a process tree found cygserver isn't started, it will not try to ask cygserver again, and it will propagate the lack of cygserver to the child processes, so they will neither try to contact cygserver. If you have a catchy way to phrase this in less words, I'd be quite happy. Btw. In the document I'm talking of the first process of a Cygwin process tree throughout. Is it clear at all what that means? For a Cygwin Terminal session that would be the mintty process. If you have this: Cygwin process 1 starts Cygwin process 2 Cygwin process 2 starts CMD.EXE CMD.EXE starts Cygwin process 3 Cygwin process 3 starts Cygwin process 4 Then you have two Cygwin process trees with Cygwin process 1 and Cygwin process 3 being the first processes in a Cygwin process tree. Is there a better way to phrase this in English? Would it make more sense to use parent or grandparent for the first process? Or any other expression? 'is not running a[t] the time' 'via an undocumented API[,] an applications[application] can fetch' 'When Cygwin stat's[stats, or: stat()s] files' 'If both[,] files and db are specified' There is a comma already. Or am I looking into the wrong line? 'Cygwin will always try the files first, then the db. ' -- is that because the db will always be more trustworthy than the files? It's because it doesn't make sense the other way around. The DBs will always have a valid reply for an existing account, thus there can't be any fallback from db to files. BTW, the POSIX permission mapping leak used to have a section heading; it's now just unmarked, inside the File Permissions section. (I'm just pointing that out.) That was deliberate. I was wondering if the lengthy description of a bordercase in permission handling really deserved its own chapter and came up with a no. Hope this helps! You've obviously put a lot of thought and effort into all
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
On Oct 23 20:06, Denis Excoffier wrote:
On 2014-10-22 11:23, Corinna Vinschen wrote:
- Drop the current working directory from the default DLL search path in
favor of Cygwin's /bin dir.
I'm not so comfortable with this one.
I use
PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog
There is no DLL at all in /my/otherdir (this is the very first place
for Windows to look for DLL's, and i think that this cannot change).
In /my/dir/bin, there is an updated version of a library also
located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC 4.9.1).
Does this mean that, under this change, cygstdc++-6.dll will be found
in /usr/bin and not in /my/dir/bin ? In fact, this is what i can
observe personnally.
Also, i don't remember that the CWD has an impact on where DLL is found (apart
from being in PATH, and apart from being the dir where the exe resides).
For a test i have commented out in cygheap.cc the line
'wcpncpy (installation_dir, ...' (and also the next one)
and the old behaviour is now back.
It seems to me that this change is a regression. Could someone please argue?
Hmm. It's hard to do the right thing here, I guess. I can see how
this is a regression in your scenario. OTOH, your scenario is not
stable. The directories in $PATH are the last ones in the DLL search
order. So, your scenario already wouldn't work if your CWD is /bin
(or /usr/bin).
From Cygwin's POV {/usr}/bin is a system dir. For security reasons it
makes sense that the system DLLs in /bin cannot be overridden, unless
it's an installation issue which should be covered by looking into the
application installation dir first.
Having said that, moving your DLLs into the application dir is really
not an option?
Does anybody else have a similar scenario to cover, which doesn't work
anymore with this change?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpUPZDG5Egdy.pgp
Description: PGP signature
Re: Threads
On 23/10/2014 16:37, Corinna Vinschen wrote:
On Oct 23 08:04, Ken Brown wrote:
On 10/23/2014 7:31 AM, Jon TURNEY wrote:
On 20/10/2014 14:03, Ken Brown wrote:
Or is there some other plausible explanation for impossible crashes?
This can't just be a result of a gdb bug, because in at least one case
the assertion can be shown to be valid by using printf instead of gdb.
[*] By impossible I mean that examination of the relevant variables in
gdb shows that the assertions are in fact true. Two ongoing examples are
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18438
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18769
As a suggestion, you might want to also take a careful look at how signal
delivery is implemented in cygwin on x86_64
I had a vague idea that there was, at some time in the past, a fix made for
register corruption on x86_64 after a signal was handled, but I can't find it
now, so maybe I imagined it.
Is this what you're thinking of?
https://cygwin.com/ml/cygwin-cvs/2014-q1/msg00020.html
But if for e.g. the flags register was getting
corrupted when a signal interrupts the main thread, that could perhaps also
explain what is being seen.
Yes, flags register corruption is exactly what Eli suggested in the other
bug report I cited.
The aforementioned patch was supposed to fix this problem and it is
definitely in the current 1.7.32 release...
I didn't mean to suggest otherwise, just that perhaps a similar problem
exists now.
So I made the attached test case to explore that. Maybe I've made an
obvious mistake with it, but on the face of it, it seems to demonstrate
something...
jon@tambora /
$ gcc signal-stress.c -Wall -O0 -g
jon@tambora /
$ ./a
failed: 2144210386 isn't equal to 2144210386, apparently
Note there is some odd load dependency. For me, it works fine when it's
the only thing running, but when I start up something CPU intensive, it
often fails...
#include assert.h
#include sys/time.h
#include signal.h
#include stdio.h
long SmartScheduleInterval = 1; /* ms */
long SmartScheduleTime = 0;
static void
SmartScheduleTimer(int sig)
{
if (sig != 0)
SmartScheduleTime += SmartScheduleInterval;
}
void
SmartScheduleStartTimer(void)
{
struct itimerval timer;
timer.it_interval.tv_sec = 0;
timer.it_interval.tv_usec = SmartScheduleInterval * 1000;
timer.it_value.tv_sec = 0;
timer.it_value.tv_usec = SmartScheduleInterval * 1000;
setitimer(ITIMER_REAL, timer, 0);
}
int main()
{
/* Set up the timer signal function */
struct sigaction act;
act.sa_handler = SmartScheduleTimer;
sigemptyset(act.sa_mask);
sigaddset(act.sa_mask, SIGALRM);
if (sigaction(SIGALRM, act, 0) 0) {
perror(sigaction failed);
return -1;
}
/* start timer */
SmartScheduleStartTimer();
/* Loop forever, doing tests which should always succeed, with lots of
signals */
int x = 0;
int i = 0;
while (1) {
x = i;
int j = x;
if (j != i)
{
printf(failed: %d isn't equal to %d, apparently\n, i, j);
break;
}
i++;
}
return 0;
}
--
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: Setup 2.774 texlive postinstall takes 10+ hours
Greetings, Don MacDougall! I wouldn't try to restart the install without figuring out why /etc/postinstall/texlive-collection-basic.sh didn't complete. Is there anything at all in /var/log/ that might provide a clue? Usually setup writes temporary files while it's executing postinstall scripts. There wasn't even a /var/log directory until the install was finished. What I finally did to get it to finish was to move all the texlive-collection files out of the postinstall directory and the install process finished all the rest quite rapidly. Then I put them back, except for the language packages, and reran the install program and one by one moved the files back out again if they stalled. In the end there were 8 that wouldn't run. In the temporary logs are a lot of error messages similar to the following three: Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. 7 [main] perl 8088 child_info_fork::abort: unable to remap Fcntl.dll to same address as parent (0x2E) - try running rebaseall Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. 6 [main] perl 8056 child_info_fork::abort: address space needed by 'MD5.dll' (0x2D) is already occupied Can't fork, trying again in 5 seconds at /usr/bin/updmap line 59. 5 [main] perl 8076 child_info_fork::abort: address space needed by 'IO.dll' (0x2F) is already occupied This could happen, if you install too many packages on a 32-bit Cygwin, or there's an interference in your system that break memory layout of applications. (I.e. BLODA) I looked for updmap but there doesn't appear to be even a /usr/bin directory, so I must be looking in the wrong place. You're looking in the wrong place. Whole Cygwin is installed in that directory. In any case, I did get the install to complete by this rather ugly method except for those 8 packages and all the language files. I don't know if this method will have fouled up anything else or not. If the log files would be of any value to you, I've put them here: http://www.macdougalls.net/cygwinlogs/ -- WBR, Andrey Repin (anrdae...@yandex.ru) 24.10.2014, 15:26 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: Threads
On Oct 24 12:05, Jon TURNEY wrote:
On 23/10/2014 16:37, Corinna Vinschen wrote:
On Oct 23 08:04, Ken Brown wrote:
Yes, flags register corruption is exactly what Eli suggested in the other
bug report I cited.
The aforementioned patch was supposed to fix this problem and it is
definitely in the current 1.7.32 release...
I didn't mean to suggest otherwise, just that perhaps a similar problem
exists now.
So I made the attached test case to explore that. Maybe I've made an
obvious mistake with it, but on the face of it, it seems to demonstrate
something...
jon@tambora /
$ gcc signal-stress.c -Wall -O0 -g
jon@tambora /
$ ./a
failed: 2144210386 isn't equal to 2144210386, apparently
So it checks i and j for equality, fails, and then comes up with
42 isn't equal to 42? This is weird...
Note there is some odd load dependency. For me, it works fine when it's the
only thing running, but when I start up something CPU intensive, it often
fails...
That's... interesting. I wonder if that only occurs in multi-core or
multi-CPU environments. The fact that i and j are not the same when
testing, but then are the same when printf is called looks like a
out-of-order execution problem.
Is it possible that we have to add CPU memory barriers to the sigdelayed
function to avoid stuff like this?
Corinna
#include assert.h
#include sys/time.h
#include signal.h
#include stdio.h
long SmartScheduleInterval = 1; /* ms */
long SmartScheduleTime = 0;
static void
SmartScheduleTimer(int sig)
{
if (sig != 0)
SmartScheduleTime += SmartScheduleInterval;
}
void
SmartScheduleStartTimer(void)
{
struct itimerval timer;
timer.it_interval.tv_sec = 0;
timer.it_interval.tv_usec = SmartScheduleInterval * 1000;
timer.it_value.tv_sec = 0;
timer.it_value.tv_usec = SmartScheduleInterval * 1000;
setitimer(ITIMER_REAL, timer, 0);
}
int main()
{
/* Set up the timer signal function */
struct sigaction act;
act.sa_handler = SmartScheduleTimer;
sigemptyset(act.sa_mask);
sigaddset(act.sa_mask, SIGALRM);
if (sigaction(SIGALRM, act, 0) 0) {
perror(sigaction failed);
return -1;
}
/* start timer */
SmartScheduleStartTimer();
/* Loop forever, doing tests which should always succeed, with lots of
signals */
int x = 0;
int i = 0;
while (1) {
x = i;
int j = x;
if (j != i)
{
printf(failed: %d isn't equal to %d, apparently\n, i, j);
break;
}
i++;
}
return 0;
}
--
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpCwlalm8rFn.pgp
Description: PGP signature
Why can't run.exe execute a shebang script directly?
I would have thought cygwin1.dll contains the code necessary to do this, like the linux kernel does. Can it be added to the dll or does it have to be added to each executable individually, such as bash.exe, run.exe, etc.? bash$ /bin/run ./try run FATAL: Could not start D:\ftp\try -- 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: Why can't run.exe execute a shebang script directly?
Greetings, John Wiersba! I would have thought cygwin1.dll contains the code necessary to do this, like the linux kernel does. Can it be added to the dll or does it have to be added to each executable individually, such as bash.exe, run.exe, etc.? bash$ /bin/run ./try run FATAL: Could not start D:\ftp\try All right except the fact that run.exe is designed to start Windows applications (or associations). It just doesn't try the cygwin magic on the files it tries to start. I suggest /bin/env instead. -- WBR, Andrey Repin (anrdae...@yandex.ru) 24.10.2014, 17:35 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: Threads
On Oct 24 14:54, Corinna Vinschen wrote: On Oct 24 12:05, Jon TURNEY wrote: On 23/10/2014 16:37, Corinna Vinschen wrote: On Oct 23 08:04, Ken Brown wrote: Yes, flags register corruption is exactly what Eli suggested in the other bug report I cited. The aforementioned patch was supposed to fix this problem and it is definitely in the current 1.7.32 release... I didn't mean to suggest otherwise, just that perhaps a similar problem exists now. So I made the attached test case to explore that. Maybe I've made an obvious mistake with it, but on the face of it, it seems to demonstrate something... jon@tambora / $ gcc signal-stress.c -Wall -O0 -g jon@tambora / $ ./a failed: 2144210386 isn't equal to 2144210386, apparently So it checks i and j for equality, fails, and then comes up with 42 isn't equal to 42? This is weird... Note there is some odd load dependency. For me, it works fine when it's the only thing running, but when I start up something CPU intensive, it often fails... That's... interesting. I wonder if that only occurs in multi-core or multi-CPU environments. The fact that i and j are not the same when testing, but then are the same when printf is called looks like a out-of-order execution problem. Is it possible that we have to add CPU memory barriers to the sigdelayed function to avoid stuff like this? I discussed this with my college Kai Tietz (many thanks to him from here), and we came up with a problem in sigdelayed in the 64 bit case: pushf is called *after* aligning the stack with andq. This alignment potentially changes the CPU flag values so the restored flags are potentially not the flags when entering sigdelayed. I just applied a patch and created new snapshots on https://cygwin.com/snapshots/ I couldn't reprocude the problem locally, so I'd be grateful if you could test if that fixes the problem in your testcase, Jon. Ken, can you check if this snapshot helps emacs along, too? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpeFY_vb15H7.pgp Description: PGP signature
Re: Why can't run.exe execute a shebang script directly?
On Oct 24 06:05, John Wiersba wrote: I would have thought cygwin1.dll contains the code necessary to do this, like the linux kernel does. Can it be added to the dll or does it have to be added to each executable individually, such as bash.exe, run.exe, etc.? bash$ /bin/run ./try run FATAL: Could not start D:\ftp\try run.exe doesn't start the executable via a Cygwin function, but via a Windows call. There's no chance for the DLL to handle shebangs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpxqXw2IHNAh.pgp Description: PGP signature
Re: Why can't run.exe execute a shebang script directly?
On 10/24/2014 07:53 AM, Corinna Vinschen wrote: On Oct 24 06:05, John Wiersba wrote: I would have thought cygwin1.dll contains the code necessary to do this, like the linux kernel does. Can it be added to the dll or does it have to be added to each executable individually, such as bash.exe, run.exe, etc.? bash$ /bin/run ./try run FATAL: Could not start D:\ftp\try run.exe doesn't start the executable via a Cygwin function, but via a Windows call. There's no chance for the DLL to handle shebangs. Of course, if you wanted to be nice, you could write a patch to run.exe that teaches it to read() the contents of a file that it is about to execute, and if it starts with a shebang, run the interpreter directly instead of handing things off to the Windows call (and maybe make this mode optional, requiring a command line option to turn on?). This is open source, after all. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Why can't run.exe execute a shebang script directly?
On Oct 24, 2014, at 7:57 AM, Eric Blake ebl...@redhat.com wrote: On 10/24/2014 07:53 AM, Corinna Vinschen wrote: On Oct 24 06:05, John Wiersba wrote: I would have thought cygwin1.dll contains the code necessary to do this, like the linux kernel does. run.exe doesn't start the executable via a Cygwin function, but via a Windows call. There's no chance for the DLL to handle shebangs. Of course, if you wanted to be nice, you could write a patch to run.exe that teaches it to read() the contents of a file that it is about to execute, and if it starts with a shebang… I get that run.exe must do low-level Win32 API things in order to suppress the console window, which is why it is currently a native app, rather than a Cygwin app, but I don’t like the idea of reinventing execve(2) inside run.exe. -- 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: Why can't run.exe execute a shebang script directly?
On Oct 24, 2014, at 7:37 AM, Andrey Repin anrdae...@yandex.ru wrote: run.exe is designed to start Windows applications (or associations). …or associations? Are you confusing run.exe with cygstart.exe? $ touch foo.txt $ run foo.txt run FATAL: Could not start C:\cygwin64\home\Warren\foo.txt $ cygstart foo.txt # Notepad opens, as expected -- 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
FW: bind-utils stdout pipe broken Cygwin x86_64 1.7.32+
Sorry to report, but it would seem the new Cygwin versions break bind-utils
9.9.5-3 -- 9.9.6-2 ability to stdout stdin.
Tested on:
CYGWIN_NT-6.1 1.7.32 - 1.7.33(0.278/5/3) 2014-10-22 10:37 x86_64 Cygwin
(w2k8r2)
CYGWIN_NT-6.3 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin (2012r2)
I just can´t seem to do anything with host or dig´s output.
Be well
$ host cygwin.org
cygwin.org has address 209.132.180.131
cygwin.org mail is handled by 10 sourceware.org.
$ dig cygwin.org
; DiG 9.9.5 cygwin.org
; (1 server found)
___
$ host cygwin.org | grep cygwin
$ dig cygwin.org | grep ANSWER
$ test=$(mktemp); host cygwin.org $test; cat $test; rm $test
$ dig | awk '/root/ {print $0}'
$ echo $(dig cygwin.org)
$ grep cygwin $(host cygwin.org)
--
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: Why can't run.exe execute a shebang script directly?
From: Corinna Vinschen corinna-cyg...@cygwin.com On Oct 24 06:05, John Wiersba wrote: I would have thought cygwin1.dll contains the code necessary to do this, like the linux kernel does. Can it be added to the dll or does it have to be added to each executable individually, such as bash.exe, run.exe, etc.? bash$ /bin/run ./try run FATAL: Could not start D:\ftp\try run.exe doesn't start the executable via a Cygwin function, but via a Windows call. There's no chance for the DLL to handle shebangs. Thanks, Corinna! This is the real reason. I thought that all (or virtually all) cygwin-supplied programs that start other programs use the cygwin1.dll execve(2) emulation to start them, because the execve emulation can be used to start *both* cygwin programs and windows native programs. Or at least it seems that way to me. Is there be in drawback to having run.exe start its target program using the execve emulation in cygwin1.dll, rather than using a Windows call to start the target executable? -- 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: Why can't run.exe execute a shebang script directly?
On 10/24/2014 09:19 AM, John Wiersba wrote: I thought that all (or virtually all) cygwin-supplied programs that start other programs use the cygwin1.dll execve(2) emulation to start them, because the execve emulation can be used to start *both* cygwin programs and windows native programs. Or at least it seems that way to me. Is there be in drawback to having run.exe start its target program using the execve emulation in cygwin1.dll, rather than using a Windows call to start the target executable? run.exe is special. In order to hide consoles, it MUST use native windows API instead of cygwin1.dll calls. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
Greetings, Corinna Vinschen! For your convenience I wrote new documentation. Since this is a TEST prerelease, the new documentation is not part of the official docs yet. Rather have a look at https://cygwin.com/preliminary-ntsec.html via an undocumented APIr should be ... API, probably. If you read it (which I seriously hope for) and it's all just incomprehensible gobbledygook to you, please say so on the mailing list cygwin AT cygwin DOT com so we have a chance to improve the documentation. I'm in the process of reading it. Goes slowly, but that's due to my head condition. It really a very good read, thank you. - /proc/cygdrive is a new symlink pointing to the current cygdrive prefix. This can be utilized in scripts to access paths via cygdrive prefix, even if the cygdrive prefix has been changed by the user. Hm. The prefix currently set to just /. $ ls -l /proc/cygdrive lrwxrwxrwx 1 anrdaemon None 0 Oct 24 20:17 /proc/cygdrive - /proc/cygdrive $ ls -l /proc/cygdrive/ ls: cannot access /proc/cygdrive/: Not a directory Is this... normal? Or what this is supposed to be at all? Shouldn't it be a simple text file containing current cygdrive prefix? - /proc/partitions now prints the windows mount points the device is mounted on. This allows to recognize the underlying Windows devices of the Cygwin raw device names. $ cat /proc/partitions major minor #blocks name win-mounts 8 0 78150744 sda 8 1 78149688 sda1 C:\dev\sdb1\ 816 78150744 sdb 817102400 sdb1 818131072 sdb2 819 77916160 sdb3 C:\ 832 488386584 sdc 833 486615520 sdc1 C:\dev\sdb1\dev\sdc1\ C:\dev\sdb1\d\ C:\dev\sdc1\ 848 312571224 sdd 849 312568641 sdd1 C:\dev\sdb1\dev\sdd1\ C:\dev\sdd1\ 864 0 sde 880 0 sdf 896 0 sdg 8 112 0 sdh I approve of this product and/or service. I would use a mountvol data around here somewhere, too. But it's useful as it is already. - New API: quotactl, designed after the Linux/BSD function, but severly severely? I'm no expert, but that's probably the right form. A slightly unrelated request, but... I just had an issue I could prevent if applying brain to hands, but... would it be a feasible request to make the output of 'uname -r' suitable for naming a file? -- WBR, Andrey Repin (anrdae...@yandex.ru) 24.10.2014, 19:51 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: Why can't run.exe execute a shebang script directly?
From: Eric Blake ebl...@redhat.com On 10/24/2014 09:19 AM, John Wiersba wrote: I thought that all (or virtually all) cygwin-supplied programs that start other programs use the cygwin1.dll execve(2) emulation to start them, because the execve emulation can be used to start *both* cygwin programs and windows native programs. Or at least it seems that way to me. Is there be in drawback to having run.exe start its target program using the execve emulation in cygwin1.dll, rather than using a Windows call to start the target executable? run.exe is special. In order to hide consoles, it MUST use native windows API instead of cygwin1.dll calls. OK -- I guess that settles it, then! Thanks! -- 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 RELEASE: Cygwin 1.7.33-0.1
Here's a function for you Andrey, in appreciation for all the work you
contribute to Cygwin:
type uname_r
uname_r is a function
uname_r ()
{
uname -r | sed -e 's/[.(/\)]/_/g' | sed -e 's/\(.*\)\(_$\)/\1/'
}
uname_r
1_7_32_0_274_5_3
On Fri, Oct 24, 2014 at 10:20 AM, Andrey Repin anrdae...@yandex.ru wrote:
Greetings, Corinna Vinschen!
For your convenience I wrote new documentation. Since this is a TEST
prerelease, the new documentation is not part of the official docs yet.
Rather have a look at
https://cygwin.com/preliminary-ntsec.html
via an undocumented APIr should be ... API, probably.
If you read it
(which I seriously hope for) and it's all just incomprehensible
gobbledygook to you, please say so on the mailing list
cygwin AT cygwin DOT com
so we have a chance to improve the documentation.
I'm in the process of reading it. Goes slowly, but that's due to my head
condition. It really a very good read, thank you.
- /proc/cygdrive is a new symlink pointing to the current cygdrive prefix.
This can be utilized in scripts to access paths via cygdrive prefix, even
if the cygdrive prefix has been changed by the user.
Hm. The prefix currently set to just /.
$ ls -l /proc/cygdrive
lrwxrwxrwx 1 anrdaemon None 0 Oct 24 20:17 /proc/cygdrive - /proc/cygdrive
$ ls -l /proc/cygdrive/
ls: cannot access /proc/cygdrive/: Not a directory
Is this... normal?
Or what this is supposed to be at all? Shouldn't it be a simple text file
containing current cygdrive prefix?
- /proc/partitions now prints the windows mount points the device is mounted
on. This allows to recognize the underlying Windows devices of the Cygwin
raw device names.
$ cat /proc/partitions
major minor #blocks name win-mounts
8 0 78150744 sda
8 1 78149688 sda1 C:\dev\sdb1\
816 78150744 sdb
817102400 sdb1
818131072 sdb2
819 77916160 sdb3 C:\
832 488386584 sdc
833 486615520 sdc1 C:\dev\sdb1\dev\sdc1\ C:\dev\sdb1\d\ C:\dev\sdc1\
848 312571224 sdd
849 312568641 sdd1 C:\dev\sdb1\dev\sdd1\ C:\dev\sdd1\
864 0 sde
880 0 sdf
896 0 sdg
8 112 0 sdh
I approve of this product and/or service.
I would use a mountvol data around here somewhere, too. But it's useful as it
is already.
- New API: quotactl, designed after the Linux/BSD function, but severly
severely? I'm no expert, but that's probably the right form.
A slightly unrelated request, but... I just had an issue I could prevent if
applying brain to hands, but... would it be a feasible request to make the
output of 'uname -r' suitable for naming a file?
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 24.10.2014, 19:51
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
--
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 RELEASE: Cygwin 1.7.33-0.1
On 10/24/2014 11:28 AM, Keith Christian wrote:
uname_r ()
{
uname -r | sed -e 's/[.(/\)]/_/g' | sed -e 's/\(.*\)\(_$\)/\1/'
}
Or for one less fork and less typing:
uname_r ()
{
uname -r | sed 's/[.(/\)]/_/g; s/_$//'
}
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
Am 24.10.2014 19:28, schrieb Keith Christian:
Here's a function for you Andrey, in appreciation for all the work you
contribute to Cygwin:
type uname_r
uname_r is a function
uname_r ()
{
uname -r | sed -e 's/[.(/\)]/_/g' | sed -e 's/\(.*\)\(_$\)/\1/'
}
uname_r
1_7_32_0_274_5_3
How about:
function uname-r () {
uname -r|sed -e 's,(,-,' -e 's,/,_,g' -e 's,),,'
}
uname-r
1.7.33-0.278_5_3
--
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 RELEASE: Cygwin 1.7.33-0.1
On 2014-10-24 13:02, Corinna Vinschen wrote:
On Oct 23 20:06, Denis Excoffier wrote:
On 2014-10-22 11:23, Corinna Vinschen wrote:
- Drop the current working directory from the default DLL search path in
favor of Cygwin's /bin dir.
I'm not so comfortable with this one.
I use
PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog
There is no DLL at all in /my/otherdir (this is the very first place
for Windows to look for DLL's, and i think that this cannot change).
In /my/dir/bin, there is an updated version of a library also
located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC 4.9.1).
Does this mean that, under this change, cygstdc++-6.dll will be found
in /usr/bin and not in /my/dir/bin ? In fact, this is what i can
observe personnally.
Also, i don't remember that the CWD has an impact on where DLL is found
(apart
from being in PATH, and apart from being the dir where the exe resides).
For a test i have commented out in cygheap.cc the line
'wcpncpy (installation_dir, ...' (and also the next one)
and the old behaviour is now back.
It seems to me that this change is a regression. Could someone please argue?
Hmm. It's hard to do the right thing here, I guess. I can see how
this is a regression in your scenario. OTOH, your scenario is not
stable. The directories in $PATH are the last ones in the DLL search
order. So, your scenario already wouldn't work if your CWD is /bin
(or /usr/bin).
Typically, the line 'PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog' is
in a Makefile, as part of some 'make check'. I don't usually build
from /usr/bin.
I was not aware that CWD was useful. IIUC, your change removes the lookup
into CWD (and replaces with a lookup to somewhere else). Who needs CWD at
the first place? These people (or specification?) will not be OK now.
From Cygwin's POV {/usr}/bin is a system dir. For security reasons it
makes sense that the system DLLs in /bin cannot be overridden, unless
it's an installation issue which should be covered by looking into the
application installation dir first.
Instead of adding the lookup of /usr/bin before the PATH, you could add
it afterwards? Or do you mean that my use is bad practice for security
reasons? That there might be some unexpected DLL somewhere in the PATH?
IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root,
not otherwise.
Having said that, moving your DLLs into the application dir is really
not an option?
Oh yes, i use it all the time. It is the job of 'make install' to also
install the appropriate DLLs. The point here is for 'make check'.
Does anybody else have a similar scenario to cover, which doesn't work
anymore with this change?
Yes please?
Regards,
Denis Excoffier.
--
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 RELEASE: Cygwin 1.7.33-0.1
On Oct 24 20:20, Andrey Repin wrote: Greetings, Corinna Vinschen! For your convenience I wrote new documentation. Since this is a TEST prerelease, the new documentation is not part of the official docs yet. Rather have a look at https://cygwin.com/preliminary-ntsec.html via an undocumented APIr should be ... API, probably. Thanks, fixed. If you read it (which I seriously hope for) and it's all just incomprehensible gobbledygook to you, please say so on the mailing list cygwin AT cygwin DOT com so we have a chance to improve the documentation. I'm in the process of reading it. Goes slowly, but that's due to my head condition. It really a very good read, thank you. Thanks, I'm glad to read that. - /proc/cygdrive is a new symlink pointing to the current cygdrive prefix. This can be utilized in scripts to access paths via cygdrive prefix, even if the cygdrive prefix has been changed by the user. Hm. The prefix currently set to just /. $ ls -l /proc/cygdrive lrwxrwxrwx 1 anrdaemon None 0 Oct 24 20:17 /proc/cygdrive - /proc/cygdrive $ ls -l /proc/cygdrive/ ls: cannot access /proc/cygdrive/: Not a directory Is this... normal? No, it's a bug. The internal cygdrive path has a trailing slash, which I have to remove for the symlink. If the cygdrive path is /, the result is an empty path, which is the same as a self-reference. I fixed that in CVS. Or what this is supposed to be at all? Shouldn't it be a simple text file containing current cygdrive prefix? As a symlink, you can use /proc/cygdrive directly as path component in a script. With a text file you couldn't do that. - /proc/partitions now prints the windows mount points the device is mounted on. This allows to recognize the underlying Windows devices of the Cygwin raw device names. [...] I approve of this product and/or service. I would use a mountvol data around here somewhere, too. But it's useful as it is already. mountvol data?!? -v? - New API: quotactl, designed after the Linux/BSD function, but severly severely? I'm no expert, but that's probably the right form. Thanks, fixed. A slightly unrelated request, but... I just had an issue I could prevent if applying brain to hands, but... would it be a feasible request to make the output of 'uname -r' suitable for naming a file? I wouldn't do that. The layout is checked by existing scripts. I wouldn't want to break that. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7eLwZweAkS.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
[Christian, please chime in]
On Oct 24 20:41, Denis Excoffier wrote:
On 2014-10-24 13:02, Corinna Vinschen wrote:
On Oct 23 20:06, Denis Excoffier wrote:
On 2014-10-22 11:23, Corinna Vinschen wrote:
- Drop the current working directory from the default DLL search path in
favor of Cygwin's /bin dir.
I'm not so comfortable with this one.
I use
PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog
There is no DLL at all in /my/otherdir (this is the very first place
for Windows to look for DLL's, and i think that this cannot change).
In /my/dir/bin, there is an updated version of a library also
located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC
4.9.1).
Does this mean that, under this change, cygstdc++-6.dll will be found
in /usr/bin and not in /my/dir/bin ? In fact, this is what i can
observe personnally.
Also, i don't remember that the CWD has an impact on where DLL is found
(apart
from being in PATH, and apart from being the dir where the exe resides).
For a test i have commented out in cygheap.cc the line
'wcpncpy (installation_dir, ...' (and also the next one)
and the old behaviour is now back.
It seems to me that this change is a regression. Could someone please
argue?
Hmm. It's hard to do the right thing here, I guess. I can see how
this is a regression in your scenario. OTOH, your scenario is not
stable. The directories in $PATH are the last ones in the DLL search
order. So, your scenario already wouldn't work if your CWD is /bin
(or /usr/bin).
Typically, the line 'PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog' is
in a Makefile, as part of some 'make check'. I don't usually build
from /usr/bin.
Sure. I was just pointing out that it's not a 100% stable method, but
dependent on the system's DLL search order, your CWD, and the fact that
the application is not installed into {/usr}/bin.
I was not aware that CWD was useful. IIUC, your change removes the lookup
into CWD (and replaces with a lookup to somewhere else). Who needs CWD at
the first place? These people (or specification?) will not be OK now.
If applications do this:
chdir(/path/of/DLLs);
dlopen(some.dll);
it wouldn't work anymore. It wouldn't work on Linux either, unless CWD
is in LD_LIBRARY_PATH or the default search path. This would work,
though:
chdir(/path/of/DLLs);
dlopen(/path/of/DLLs/some.dll);
Unfortunately the same doesn't work if the application calls execve
instead of dlopen because we can't add our LD_LIBRARY_PATH magic
there.
From Cygwin's POV {/usr}/bin is a system dir. For security reasons it
makes sense that the system DLLs in /bin cannot be overridden, unless
it's an installation issue which should be covered by looking into the
application installation dir first.
Instead of adding the lookup of /usr/bin before the PATH, you could add
it afterwards?
No. You don't expect this kind of flexibility in the Win32 API, do you?
The way it works is, there's a call SetDllDirectory which replaces the .
in the DLL search path with the directory given as argument. The search
order is always this:
application dir
dir given in SetDllDirecory (Cygwin's bin)
system dirs
$PATH
Or do you mean that my use is bad practice for security
reasons? That there might be some unexpected DLL somewhere in the PATH?
IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root,
not otherwise.
Not quite. LD_LIBRARY_PATH is only ignored if the excutable is a
suid/sgid executable. Unfortunately we don't have LD_LIBRARY_PATH at
all when running execve (but we have in dlopen).
Having said that, moving your DLLs into the application dir is really
not an option?
Oh yes, i use it all the time. It is the job of 'make install' to also
install the appropriate DLLs. The point here is for 'make check'.
Yeah.
Sigh.
I don't like the idea either that this simple change breaks existing
scenarios. I'm inclined to revert this change.
Christian, would you mind terribly to re-add the tweak to postfix
to set $PATH?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpAWI3ymFyV5.pgp
Description: PGP signature
[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.2
Hi Cygwin friends and users,
I just released a 2nd TEST version of the next upcoming Cygwin release,
1.7.33-0.2.
This test version comes with a few changes compared to the former test
version 1.7.33-0.2:
- New API: stime (SVr4).
- Provide Cygwin documentation (PDFs and HTML) for offline usage in
/usr/share/doc/cygwin-${version}.
- (Hopefully) fix a bug in signal handling which could return to the
interrupted function with wrong CPU flags.
- Fix /proc/cygdrive if the cygdrive prefix is /.
If you want to help testing this new release (which I seriously hope
for), you can find it in your setup-x86.exe or setup-x86_64.exe as
test release.
The major change in this new release is the new method to read account
(passwd and group) information from the Windows user databases directly,
without the requirement to generate /etc/passwd and /etc/group files to
generate Unix-like uid and gid.
For your convenience I wrote new documentation. Since this is a TEST
prerelease, the new documentation is not part of the official docs yet.
Rather have a look at
https://cygwin.com/preliminary-ntsec.html
If you read it
(which I seriously hope for) and it's all just incomprehensible
gobbledygook to you, please say so on the mailing list
cygwin AT cygwin DOT com
so we have a chance to improve the documentation.
Please give this TEST release a try.
If you find problems in the new features or regressions compared to the
current stable release 1.7.32, please report them to the public mailing
list
cygwin AT cygwin DOT com
Following is a list of changes in this new release:
What's new:
---
- Cygwin can now generate passwd/group entries directly from Windows
user databases (local SAM or Active Directory), thus allowing to run
Cygwin without having to create /etc/passwd and /etc/group files.
Introduce /etc/nsswitch.conf file to configure passwd/group handling.
For bordercase which require to use /etc/passwd and /etc/group files,
change mkpasswd/mkgroup to generate passwd/group entries compatible
with the entries read from SAM/AD.
- /proc/cygdrive is a new symlink pointing to the current cygdrive prefix.
This can be utilized in scripts to access paths via cygdrive prefix, even
if the cygdrive prefix has been changed by the user.
- /proc/partitions now prints the windows mount points the device is mounted
on. This allows to recognize the underlying Windows devices of the Cygwin
raw device names.
- New API: quotactl, designed after the Linux/BSD function, but severly
restricted: Windows only supports user block quotas on NTFS, no group
quotas, no inode quotas, no time constraints.
- New APIs: ffsl, ffsll (glibc extensions).
- New API: stime (SVr4).
- Provide Cygwin documentation (PDFs and HTML) for offline usage in
/usr/share/doc/cygwin-${version}.
What changed:
-
- New internal exception handling based on SEH on 64 bit Cygwin.
- Revamp Solaris ACL implementation to more closely work like POSIX ACLs
are supposed to work. Finally implement a CLASS_OBJ emulation. Update
getfacl(1)/setfacl(1) accordingly.
- Drop the current working directory from the default DLL search path in
favor of Cygwin's /bin dir.
- Improve various header files for C++- and standards-compliance.
- Doug Lea malloc implementation update from 2.8.3 to the latest 2.8.6.
Bug Fixes
-
- Per POSIX, dirfd(3) now returns EINVAL rather than EBADF on invalid
directory stream.
- Fix a resource leak in rmdir(2).
- Fix fchmod(2)/fchown(2)/fsetxattr(2) in case the file got renamed after
open and before calling one of the affected functions.
Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00517.html
- Handle Netapp-specific problem in statvfs(2)/fstatvfs(2).
Addresses: https://cygwin.com/ml/cygwin/2014-06/msg00425.html
- Fix chown(2) on ptys in a corner case.
- Generate correct error when a path is inaccessible due to missing permissions.
Addresses: https://cygwin.com/ml/cygwin-developers/2014-10/msg00010.html
- Don't hang in accept calls if socket is no listener. Set errno to EINVAL
instead. Don't hang in read/recv/recvfrom/recvmsg calls if socket is
connection oriented and not connected. Set errno to ENOTCONN instead.
- Don't allow seeking on serial lines and sockets. Set errno to ESPIPE
instead.
Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00319.html
- Fix output of /proc/PID/statm.
- Fix a SEGV in cygcheck if the environment variable COMSPEC is not, or
incorrectly set.
Addresses: https://cygwin.com/ml/cygwin/2014-10/msg00292.html
To install 32-bit Cygwin use http://cygwin.com/setup-x86.exe
To install 64 bit Cygwin use http://cygwin.com/setup-x86_64.exe
If you're already running a 32 bit version of Cygwin on 64 bit Windows
machines, you can continue to do so. If you're planning a new install
of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit
Cygwin version, unless you need certain packages not yet
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.2
On Oct 24 21:52, Corinna Vinschen wrote:
Hi Cygwin friends and users,
I just released a 2nd TEST version of the next upcoming Cygwin release,
1.7.33-0.2.
This test version comes with a few changes compared to the former test
version 1.7.33-0.2:
Grr. Make that 1.7.33-0.1 here. Sorry.
Corinna
- New API: stime (SVr4).
- Provide Cygwin documentation (PDFs and HTML) for offline usage in
/usr/share/doc/cygwin-${version}.
- (Hopefully) fix a bug in signal handling which could return to the
interrupted function with wrong CPU flags.
- Fix /proc/cygdrive if the cygdrive prefix is /.
[...]
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpthznotu4uB.pgp
Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
Corinna Vinschen wrote:
[Christian, please chime in]
On Oct 24 20:41, Denis Excoffier wrote:
From Cygwin's POV {/usr}/bin is a system dir. For security reasons it
makes sense that the system DLLs in /bin cannot be overridden, unless
it's an installation issue which should be covered by looking into the
application installation dir first.
Instead of adding the lookup of /usr/bin before the PATH, you could add
it afterwards?
No. You don't expect this kind of flexibility in the Win32 API, do you?
[The *LIBPATH variables from MS OS/2 (1987) never made it to Win API :-]
The way it works is, there's a call SetDllDirectory which replaces the .
in the DLL search path with the directory given as argument. The search
order is always this:
application dir
dir given in SetDllDirecory (Cygwin's bin)
system dirs
$PATH
Or do you mean that my use is bad practice for security
reasons? That there might be some unexpected DLL somewhere in the PATH?
IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root,
not otherwise.
Not quite. LD_LIBRARY_PATH is only ignored if the excutable is a
suid/sgid executable. Unfortunately we don't have LD_LIBRARY_PATH at
all when running execve (but we have in dlopen).
Having said that, moving your DLLs into the application dir is really
not an option?
Oh yes, i use it all the time. It is the job of 'make install' to also
install the appropriate DLLs. The point here is for 'make check'.
Yeah.
Sigh.
I don't like the idea either that this simple change breaks existing
scenarios. I'm inclined to revert this change.
Christian, would you mind terribly to re-add the tweak to postfix
to set $PATH?
No problem.
Another possible solution:
Check for e.g. CYGWIN_DLLPATH environment variable before calling
SetDllDirectory().
If unset or empty, call SetDllDirectory(X:\path_to_cygwin\bin);
else if set to ., do nothing.
else call SetDllDirectory(CYGWIN_DLLPATH);
The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make
check'.
Possible enhancement: If AddDllDirectory() is available (= Win8),
accept a real search path in CYGWIN_DLLPATH.
Christian
--
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
cygclang.dll breaks terminal output when used in Python bindings
I use a Vim plugin called clang_complete for C/C++ code completion which interfaces with Clang using Clang's python bindings. After updating Cygwin, the terminal output of Vim is garbled as soon as the plugin uses the Clang Python bindings. I tracked down the exact revision (188615) of LLVM/Clang which cause the problem and the diff for that revision is at the bottom of this message. Basically it changes the way it looks up terminal capabilities in such a way that it think Cygwin can't display colors which causes it to change terminal output settings. I was able to fix the problem by installing the libncurses-devel package and recompiling LLVM/Clang. Should libncurses-devel be a dependency of libclang or is there another way to fix this problem? Thanks, Jacob Niehus --- lib/Support/Unix/Process.inc(revision 188614) +++ lib/Support/Unix/Process.inc(revision 188615) @@ -240,10 +240,12 @@ } #ifdef HAVE_TERMINFO -// We manually declare these two extern functions because finding the correct +// We manually declare these extern functions because finding the correct // headers from various terminfo, curses, or other sources is harder than // writing their specs down. extern C int setupterm(char *term, int filedes, int *errret); +extern C struct term *set_curterm(struct term *termp); +extern C int del_curterm(struct term *termp); extern C int tigetnum(char *capname); #endif @@ -272,7 +274,15 @@ // // The 'tigetnum' routine returns -2 or -1 on errors, and might return 0 if // the terminfo says that no colors are supported. - if (tigetnum(const_castchar *(colors)) 0) + bool HasColors = tigetnum(const_castchar *(colors)) 0; + + // Now extract the structure allocated by setupterm and free its memory + // through a really silly dance. + struct term *termp = set_curterm((struct term *)0); + (void)del_curterm(termp); // Drop any errors here. + + // Return true if we found a color capabilities for the current terminal. + if (HasColors) return true; #endif -- 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 RELEASE: Cygwin 1.7.33-0.1
On Oct 24 22:16, Christian Franke wrote:
Corinna Vinschen wrote:
[Christian, please chime in]
On Oct 24 20:41, Denis Excoffier wrote:
From Cygwin's POV {/usr}/bin is a system dir. For security reasons it
makes sense that the system DLLs in /bin cannot be overridden, unless
it's an installation issue which should be covered by looking into the
application installation dir first.
Instead of adding the lookup of /usr/bin before the PATH, you could add
it afterwards?
No. You don't expect this kind of flexibility in the Win32 API, do you?
[The *LIBPATH variables from MS OS/2 (1987) never made it to Win API :-]
The way it works is, there's a call SetDllDirectory which replaces the .
in the DLL search path with the directory given as argument. The search
order is always this:
application dir
dir given in SetDllDirecory (Cygwin's bin)
system dirs
$PATH
Or do you mean that my use is bad practice for security
reasons? That there might be some unexpected DLL somewhere in the PATH?
IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root,
not otherwise.
Not quite. LD_LIBRARY_PATH is only ignored if the excutable is a
suid/sgid executable. Unfortunately we don't have LD_LIBRARY_PATH at
all when running execve (but we have in dlopen).
Having said that, moving your DLLs into the application dir is really
not an option?
Oh yes, i use it all the time. It is the job of 'make install' to also
install the appropriate DLLs. The point here is for 'make check'.
Yeah.
Sigh.
I don't like the idea either that this simple change breaks existing
scenarios. I'm inclined to revert this change.
Christian, would you mind terribly to re-add the tweak to postfix
to set $PATH?
No problem.
Thanks, I'm relieved.
Another possible solution:
Check for e.g. CYGWIN_DLLPATH environment variable before calling
SetDllDirectory().
If unset or empty, call SetDllDirectory(X:\path_to_cygwin\bin);
else if set to ., do nothing.
else call SetDllDirectory(CYGWIN_DLLPATH);
The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make
check'.
Hmm. This requirement to set CYGWIN_DLLPATH would be far from obvious
for the user, though.
Possible enhancement: If AddDllDirectory() is available (= Win8), accept a
real search path in CYGWIN_DLLPATH.
Per MSDN, AddDllDirectory only works for LoadLibrary{Ex}, and the DLL
search order when using SetDefaultDllDirectories looks entirely
different from the other default search orders(*).
Even if it works for CreateProcess as well, the probably worst problem
is that $PATH is not evaluated anymore.
OTOH, this might allow us to redefine the DLL search path in a way which
enables LD_LIBRARY_PATH handling for Cygwin, but a patch to use this
stuff would be pretty intrusive.
Thanks,
Corinna
(*)
http://msdn.microsoft.com/en-us/library/windows/desktop/hh310515%28v=vs.85%29.aspx
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpCHt_0YjaxV.pgp
Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
2014-10-24 22:16, Christian Franke wrote: Corinna Vinschen wrote: Sigh. I don't like the idea either that this simple change breaks existing scenarios. I'm inclined to revert this change. Christian, would you mind terribly to re-add the tweak to postfix to set $PATH? No problem. Another possible solution: Check for e.g. CYGWIN_DLLPATH environment variable before calling SetDllDirectory(). If unset or empty, call SetDllDirectory(X:\path_to_cygwin\bin); else if set to ., do nothing. else call SetDllDirectory(CYGWIN_DLLPATH); The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make check'. I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of the Makefile will do the job. Possible enhancement: If AddDllDirectory() is available (= Win8), accept a real search path in CYGWIN_DLLPATH. Also perhaps you can use yet another subitem in the CYGWIN environment variable? Denis Excoffier. -- 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
TEST RELEASE: Cygwin 1.7.33-0.2
Hi Cygwin friends and users,
I just released a 2nd TEST version of the next upcoming Cygwin release,
1.7.33-0.2.
This test version comes with a few changes compared to the former test
version 1.7.33-0.2:
- New API: stime (SVr4).
- Provide Cygwin documentation (PDFs and HTML) for offline usage in
/usr/share/doc/cygwin-${version}.
- (Hopefully) fix a bug in signal handling which could return to the
interrupted function with wrong CPU flags.
- Fix /proc/cygdrive if the cygdrive prefix is /.
If you want to help testing this new release (which I seriously hope
for), you can find it in your setup-x86.exe or setup-x86_64.exe as
test release.
The major change in this new release is the new method to read account
(passwd and group) information from the Windows user databases directly,
without the requirement to generate /etc/passwd and /etc/group files to
generate Unix-like uid and gid.
For your convenience I wrote new documentation. Since this is a TEST
prerelease, the new documentation is not part of the official docs yet.
Rather have a look at
https://cygwin.com/preliminary-ntsec.html
If you read it
(which I seriously hope for) and it's all just incomprehensible
gobbledygook to you, please say so on the mailing list
cygwin AT cygwin DOT com
so we have a chance to improve the documentation.
Please give this TEST release a try.
If you find problems in the new features or regressions compared to the
current stable release 1.7.32, please report them to the public mailing
list
cygwin AT cygwin DOT com
Following is a list of changes in this new release:
What's new:
---
- Cygwin can now generate passwd/group entries directly from Windows
user databases (local SAM or Active Directory), thus allowing to run
Cygwin without having to create /etc/passwd and /etc/group files.
Introduce /etc/nsswitch.conf file to configure passwd/group handling.
For bordercase which require to use /etc/passwd and /etc/group files,
change mkpasswd/mkgroup to generate passwd/group entries compatible
with the entries read from SAM/AD.
- /proc/cygdrive is a new symlink pointing to the current cygdrive prefix.
This can be utilized in scripts to access paths via cygdrive prefix, even
if the cygdrive prefix has been changed by the user.
- /proc/partitions now prints the windows mount points the device is mounted
on. This allows to recognize the underlying Windows devices of the Cygwin
raw device names.
- New API: quotactl, designed after the Linux/BSD function, but severly
restricted: Windows only supports user block quotas on NTFS, no group
quotas, no inode quotas, no time constraints.
- New APIs: ffsl, ffsll (glibc extensions).
- New API: stime (SVr4).
- Provide Cygwin documentation (PDFs and HTML) for offline usage in
/usr/share/doc/cygwin-${version}.
What changed:
-
- New internal exception handling based on SEH on 64 bit Cygwin.
- Revamp Solaris ACL implementation to more closely work like POSIX ACLs
are supposed to work. Finally implement a CLASS_OBJ emulation. Update
getfacl(1)/setfacl(1) accordingly.
- Drop the current working directory from the default DLL search path in
favor of Cygwin's /bin dir.
- Improve various header files for C++- and standards-compliance.
- Doug Lea malloc implementation update from 2.8.3 to the latest 2.8.6.
Bug Fixes
-
- Per POSIX, dirfd(3) now returns EINVAL rather than EBADF on invalid
directory stream.
- Fix a resource leak in rmdir(2).
- Fix fchmod(2)/fchown(2)/fsetxattr(2) in case the file got renamed after
open and before calling one of the affected functions.
Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00517.html
- Handle Netapp-specific problem in statvfs(2)/fstatvfs(2).
Addresses: https://cygwin.com/ml/cygwin/2014-06/msg00425.html
- Fix chown(2) on ptys in a corner case.
- Generate correct error when a path is inaccessible due to missing permissions.
Addresses: https://cygwin.com/ml/cygwin-developers/2014-10/msg00010.html
- Don't hang in accept calls if socket is no listener. Set errno to EINVAL
instead. Don't hang in read/recv/recvfrom/recvmsg calls if socket is
connection oriented and not connected. Set errno to ENOTCONN instead.
- Don't allow seeking on serial lines and sockets. Set errno to ESPIPE
instead.
Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00319.html
- Fix output of /proc/PID/statm.
- Fix a SEGV in cygcheck if the environment variable COMSPEC is not, or
incorrectly set.
Addresses: https://cygwin.com/ml/cygwin/2014-10/msg00292.html
To install 32-bit Cygwin use http://cygwin.com/setup-x86.exe
To install 64 bit Cygwin use http://cygwin.com/setup-x86_64.exe
If you're already running a 32 bit version of Cygwin on 64 bit Windows
machines, you can continue to do so. If you're planning a new install
of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit
Cygwin version, unless you need certain packages not yet
