DS_FORCE_REDISCOVERY lookup slows ssh logon

2013-06-07 Thread Daniel Colascione
In sec_auth.cc, get_server_groups contains this clause:

  if (get_logon_server (domain, server, false)
  && !get_user_groups (server, grp_list, user, domain)
  && get_logon_server (domain, server, true))
get_user_groups (server, grp_list, user, domain);

The first call to get_logon_server retrieves cached domain information. We try
to look up user groups based on this information, and if fail to find this group
information (for any reason), we re-query the AD domain, get a new server, and
try again.

get_logon_server is a thin wrapper around DsGetDcName; get_logon_server's third
parameter determines whether we pass the DS_FORCE_REDISCOVERY flag to
DsGetDcName. DsGetDcName's documentation suggests that when doing AD operations,
we first retrieve cached information (by omitting DS_FORCE_REDISCOVERY), try
doing whatever it is that we're going to do, and if we can't reach the domain
controller, ask for another DC name, this time with DS_FORCE_REDISCOVERY, and
having found a better DC, try the operation again.

The problem I'm having is that this rediscover-and-retry step is slowing down my
ssh logons by about three seconds. The DCs on my network (for reasons I don't
understand) reject anonymous connections to PIPE\SAMR, making NetUserGetGroups
fail with ERROR_ACCESS_DENIED. The first call to get_user_groups fails almost
instantaneously, but there's a delay of about three seconds querying the second
server, the one found when we call get_logon_server (domain, server, true), and
this second call also eventually fails with ERROR_ACCESS_DENIED, probably
because the failure is a matter of policy, not of connectivity.

Would it be possible not to make the second call to NetUserGetGroups if the
first fails for a reason that doesn't have anything to do with network
connectivity? The purpose of DS_FORCE_REDISCOVERY seems to be to support
failover, and it doesn't seem useful to try a different server if we
successfully asked the first server and it just happened to say "no".

(By the way: how on earth does logon eventually succeed if group enumeration
fails? I'm using the stored-password authentication method, and when sshd
eventually connects, my user (according to whoami.exe /priv) is a member of the
groups I expect.)



signature.asc
Description: OpenPGP digital signature


Re: pthread_join() problem

2013-06-07 Thread David Stacey

On 07/06/13 16:58, Christopher Faylor wrote:

On Mon, Jun 03, 2013 at 12:01:02PM +0200, Corinna Vinschen wrote:

>On Jun  2 23:01, David Stacey wrote:

>>I'm trying to get Poco[1] working under Cygwin, and have hit a
>>problem with the way it manages its threads. A short example
>>(attached) shows what's going on.
>>
>>Poco creates a global object that is used for managing various
>>threads. In the destructor, the class calls pthread_join() to wait
>>for the threads to finish. This works in Fedora (and presumably
>>other Linux variants), but under Cygwin this call never returns.
>>Note that the object is global, and so pthread_join() is being
>>called after main() has returned and the global variables are being
>>mopped up.
>>
>>In the attached example, the problem only exists if the
>>'thread_container' object is global. When run in this way,
>>pthread_join() never returns and the programme locks up. If
>>'thread_container' is moved local to main() then the programme works
>>correctly. Sadly, I can't make such a trivial fix to the Poco code,
>>which rather relies on this object being global.
>>
>>The attached example (and indeed Poco) runs fine under Fedora 18
>>x64, but locks up on Cygwin (32-bit; haven't tried 64-bit). Problem
>>exists with a vanilla cygwin-1.7.18-1 and the most recent snapshot
>>(2013-06-02).

>
>Thanks for the simple testcase!
>
>I tracked this down to a problem in the process exit handling which
>disallowed pthreads to exit when process exit was in progress (and
>running the global destructors is part of the process exit).  I fixed
>that in CVS.
>
>I'm just uploading a 2013-06-03 snapshot tohttp://cygwin.com/snapshots/
>as well as generating a 1.7.9-10 cygwin package for the 64 bit test
>distro.  Please give either one of them a try, especially with poco.

I've reworked this change since Corinna's fix was to what should have
been obsolete code.  A new snapshot should be uploaded soon.

Could you confirm that things still work as expected?


Thank you for looking at this problem and for providing a new snapshot. 
I have tested the 2013-06-07 snapshot, and can confirm that both my 
testcase and Poco threads function correctly.


Many thanks once again,

Dave.


--
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



get_myaddress error with nfsd

2013-06-07 Thread Bryan Chua
I just upgraded my cygwin installation to 1.7.20-1 this morning and my nfsd 
server no longer starts with this error in /var/log/nfsd.log

get_myaddress: ioctl: Invalid argument

Mountd has the same error but portmap starts fine.

I pulled down the source for nfs-server and only see one ioctl in nfsd.c and 
one in mountd.c and no references to get_myaddress.

Has anyone else experienced this?  I am not sure where to start looking.

-- bryan

--
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: Can't get bind named to run.

2013-06-07 Thread Yaakov (Cygwin/X)

On 2013-04-26 23:22, Rick McCombs AD5DU wrote:

This is not a show stopper, but I can get named to run.


Please try again with 9.9.3-P1.


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: [TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)

2013-06-07 Thread Warren Young

On 6/6/2013 16:10, David Stacey wrote:


Thanks to Warren and Corinna for their considerable effort in getting
this working.


Thank you, Davids, for your testing. :)

I'm now nervously considering RFU'ing a -3 version, differing only in 
removing the "posixmand" stuff.  You'll have two choices only again: BSD 
type mandatory locking, or pure POSIX mode.


I might RFU it as test-only until Achim and Yaakov try it, then promote 
it to curr if they are happy with it.


--
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: Cygwin64: mkshortcut - Segmentation fault

2013-06-07 Thread Corinna Vinschen
On Jun  7 18:18, Vasiliy wrote:
> I vote for this issue be double-checked:
> 
> 1) there is only one (the latest one provided by setup) cygwin1.dll in my 
> $PATH:
> $ which cygwin1.dll
> /usr/bin/cygwin1.dll
> 
> $ uname -a
> CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64 Cygwin
> 
> and rebaseall is not (has not been) designed for a 64bit installation
> (both system and Cygwin are 64-bit)

Rebaseall supports 64 bit just fine, at least the one from the newer
rebase package in the 64 bit test distro.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
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



Fwd: Cygwin64: mkshortcut - Segmentation fault

2013-06-07 Thread Vasiliy
I vote for this issue be double-checked:

1) there is only one (the latest one provided by setup) cygwin1.dll in my $PATH:
$ which cygwin1.dll
/usr/bin/cygwin1.dll

$ uname -a
CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64 Cygwin

and rebaseall is not (has not been) designed for a 64bit installation
(both system and Cygwin are 64-bit)

2) provided in (the latest by setup) cygutils 1.4.12-2 mkshortcut.exe
was, in fact, compled with a mismatched version of cygwin1.dll

3) cygport all from the cygutils 1.4.12-2 sources installs, indeed,
libcygicons.dll.a, as opposed to the correct spelling: libicons.dll.a

Please, indeed, take a look at the content you've just attached:

Attachment: cygutils-extra.txt
Description: Text document
...
/usr/bin/cygicons-0.dll
...
/usr/lib/libcygicons.dll.a
/usr/lib/libcygicons.la

and check the content of "libcygicons.la" (should be "libicons.la" as well)

Best,
Vasiliy


-- Forwarded message --
From: Charles Wilson 
To: The Cygwin Mailing List 
Date: Fri, 07 Jun 2013 09:59:03 -0400
Subject: Re: Fwd: Cygwin64: mkshortcut - Segmentation fault
References: 
 

I have no idea what this means. The contents of cygutils,
cygutils-extra, cygutils-x11 are as attached.

--
Chuck



-- Forwarded message --
From: Charles Wilson 
To: The Cygwin Mailing List 
Date: Fri, 07 Jun 2013 09:56:08 -0400
Subject: Re: Cygwin64: mkshortcut - Segmentation fault
References: 

Unfortunately, this is not a problem, per se, within mkshortcut
itself. It's a system issue; make sure there are no other
cygwin1.dll's on your system or in your $PATH. Finally, you could try
manually running rebaseall in your 64bit installation, and then
rebooting.

--
Chuck


-- Forwarded message --
From: Vasiliy
Date: Fri, Jun 7, 2013 at 3:33 PM
Subject: Fwd: Cygwin64: mkshortcut - Segmentation fault
To: cygwin


Please, check/note:
> libcygicons.dll.a < is being *installed* to /usr/lib from the sources instead 
> of > libicons.dll.a < compiled (!)

Best,
Vasiliy


-- Forwarded message --
From: Vasiliy
Date: Fri, Jun 7, 2013 at 2:35 PM
Subject: Cygwin64: mkshortcut - Segmentation fault
To: cygwin

--
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: pthread_join() problem

2013-06-07 Thread Corinna Vinschen
On Jun  7 18:16, Denis Excoffier wrote:
> 
> On 2013-06-07 17:58, Christopher Faylor wrote:
> > I've reworked this change since Corinna's fix was to what should have
> > been obsolete code.  A new snapshot should be uploaded soon.
> > 
> Compared to the 1.7.20, the new snapshot (20130607) contains 
> /usr/include/stdatomic.h
> Is it OK?

Yes, it's a new newlib header.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
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: pthread_join() problem

2013-06-07 Thread Denis Excoffier

On 2013-06-07 17:58, Christopher Faylor wrote:
> I've reworked this change since Corinna's fix was to what should have
> been obsolete code.  A new snapshot should be uploaded soon.
> 
Compared to the 1.7.20, the new snapshot (20130607) contains 
/usr/include/stdatomic.h
Is it OK?

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: pthread_join() problem

2013-06-07 Thread Christopher Faylor
On Mon, Jun 03, 2013 at 12:01:02PM +0200, Corinna Vinschen wrote:
>On Jun  2 23:01, David Stacey wrote:
>> I'm trying to get Poco[1] working under Cygwin, and have hit a
>> problem with the way it manages its threads. A short example
>> (attached) shows what's going on.
>> 
>> Poco creates a global object that is used for managing various
>> threads. In the destructor, the class calls pthread_join() to wait
>> for the threads to finish. This works in Fedora (and presumably
>> other Linux variants), but under Cygwin this call never returns.
>> Note that the object is global, and so pthread_join() is being
>> called after main() has returned and the global variables are being
>> mopped up.
>> 
>> In the attached example, the problem only exists if the
>> 'thread_container' object is global. When run in this way,
>> pthread_join() never returns and the programme locks up. If
>> 'thread_container' is moved local to main() then the programme works
>> correctly. Sadly, I can't make such a trivial fix to the Poco code,
>> which rather relies on this object being global.
>> 
>> The attached example (and indeed Poco) runs fine under Fedora 18
>> x64, but locks up on Cygwin (32-bit; haven't tried 64-bit). Problem
>> exists with a vanilla cygwin-1.7.18-1 and the most recent snapshot
>> (2013-06-02).
>
>Thanks for the simple testcase!
>
>I tracked this down to a problem in the process exit handling which
>disallowed pthreads to exit when process exit was in progress (and
>running the global destructors is part of the process exit).  I fixed
>that in CVS.
>
>I'm just uploading a 2013-06-03 snapshot to http://cygwin.com/snapshots/
>as well as generating a 1.7.9-10 cygwin package for the 64 bit test
>distro.  Please give either one of them a try, especially with poco.

I've reworked this change since Corinna's fix was to what should have
been obsolete code.  A new snapshot should be uploaded soon.

Could you confirm that things still work as expected?

cgf

--
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: Use of mkpasswd and mkgroup for bigger organizations

2013-06-07 Thread Larry Hall (Cygwin)

On 6/6/2013 7:54 PM, DESMET, JO wrote:

Trying to suggest an update to documentation and the default output after 
starting your Cygwin shell the first time
Bigger organizations will by default have their users on the domain.

Now oftern the first time after being installed Cygwin, the following message 
will appear:
Your group is currently "mkpasswd"


If this is the case, this suggests that querying your domain for user 
information is having some "difficulties".  000-cygwin-post-install.sh post

install script uses the -c flag for both mkpasswd and mkgroup to put the
current user's info in these files directly, without grabbing any other
users' info from the domain.  If this isn't working for you, you may have
restricted access to your DC(s).  Check with your local administrators about
this.


And will further suggest to execute the following:
mkpasswd -l [-d] > /usr/passwd
mkgroup -l [-d] > /usr/group

^
Typo alert!


With the note that -d is for domain users.

Now you have a huge domain etc ... it runs forever ... geez downloading the 
whole domain?
Man, google, documentation, all has very less to mention about this.





'man' for these commands has the same info.


First time users and even repeat users (I am doing a fresh install like what 
... once every 3 year ...), blindly follow that of course.
I think in most setups, users needing access to a pc installation are already 
setup as users on that PC, even as domain users ...
So I think it would be beneficial to further explain what the -d really does 
(taking a long time doing something),
And maybe to advise running
mkgroup -l -c > /usr/group
mkpasswd -l -c > /usr/passwd

   ^^^
Again, typo alert!

Adding a few more words with some background here would be beneficial,
though if the -c flag is working for you outside of "setup.exe" but not as
part of the install itself, that may point to a more interesting issue.
But back to the documentation issue.  Care to craft some wording describing
the flags in a bit more detail and why/when it makes sense to user them?

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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] Updated: Cygwin 1.7.19

2013-06-07 Thread Corinna Vinschen
On Jun  7 14:29, Nick Lowe wrote:
> I do not think I explained myself properly, sorry: Cygwin would
> previously read the
> obcaseinsensitve value under Windows 2000 to emulate the case
> insensitive behaviour of Windows XP and newer where obcaseinsensitive
> was present in the registry.
> 
> The registry key does not represent the active state of case
> sensitivity, so it is surely the wrong thing to query and show in
> cygcheck as it only shows what the state is pending a reboot. Surely
> it would be better now to query how the case sensitivity actually is
> here and show that, and get rid of all references to
> obcaseinsensitive, which is a configuration parameter and private
> implementation detail of kernel?

Not from my POV, no.  The registry key is what the user has to change to
get case sensitive behaviour.  We want to know if the user actually
changed it in the first place, otherwise we can point to that info in
case of a case-sensitivity related problem.  The active state may be
interesting as well, but additionally to the registry key info and, as
far as I'm concerned, it's a minor problem.

But, anyway, http://cygwin.com/acronyms/#PTC


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
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



[ANNOUNCEMENT] Updated: shutdown 1.10-1

2013-06-07 Thread Frank Fesevur
A new version of the Cygwin shutdown 1.10-1 has been released and can
be found at a server near you.

BACKWARD COMPATIBILITY NOTE
===
Cygwin shutdown gives a POSIX/Linux-like shutdown experience and tries
to mimic the common Linux shutdown command line options as much as
possible. Therefore the short option for --hibernate has been changed
from -h to -b and -h is now the short for --halt.

FULL CHANGELOG (from shutdown-1.9-1)

* Changed the short option for hibernate from -h to -b.
* Added -h, --halt as additional option for shutdown and -c, --cancel
as additional option for abort.
* Updated shutdown.8 man pages to reflect these changes.
* Fixed typo: changed text InitateSystemShutdown to
InitiateSystemShutdownEx in the two usage() functions in shutdown.c
and in shutdown.8 and reboot.8

Regards,
Frank

*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is
available starting at this URL.

--
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: Fwd: Cygwin64: mkshortcut - Segmentation fault

2013-06-07 Thread Charles Wilson

On 6/7/2013 9:33 AM, Vasiliy wrote:

Please, check/note:

libcygicons.dll.a < is being *installed* to /usr/lib from the sources instead of > 
libicons.dll.a < compiled (!)


I have no idea what this means. The contents of cygutils, 
cygutils-extra, cygutils-x11 are as attached.


--
Chuck



/usr/bin/cygstart.exe
/usr/bin/mkshortcut.exe
/usr/bin/readshortcut.exe
/usr/share/man/man1/cygstart.1.gz
/usr/share/man/man1/mkshortcut.1.gz
/usr/share/man/man1/readshortcut.1.gz
/usr/bin/banner.exe
/usr/bin/conv.exe
/usr/bin/cygdrop.exe
/usr/bin/cygicons-0.dll
/usr/bin/dump.exe
/usr/bin/getclip.exe
/usr/bin/ipck
/usr/bin/lpr.exe
/usr/bin/msgtool.exe
/usr/bin/putclip.exe
/usr/bin/semstat.exe
/usr/bin/semtool.exe
/usr/bin/shmtool.exe
/usr/bin/winln.exe
/usr/include/cygicons.h
/usr/lib/libcygicons.dll.a
/usr/lib/libcygicons.la
/usr/share/doc/cygutils/AUTHORS
/usr/share/doc/cygutils/ChangeLog
/usr/share/doc/cygutils/COPYING
/usr/share/doc/cygutils/cygicons/README
/usr/share/doc/cygutils/HOW-TO-CONTRIBUTE
/usr/share/doc/cygutils/licenses/COPYING.BSD-no-advert
/usr/share/doc/cygutils/licenses/COPYING.GPLv2
/usr/share/doc/cygutils/licenses/COPYING.GPLv3
/usr/share/doc/cygutils/lpr/README
/usr/share/doc/cygutils/NEWS
/usr/share/doc/cygutils/PROGLIST
/usr/share/doc/cygutils/README
/usr/share/doc/cygutils/TODO
/usr/share/doc/Cygwin/cygutils.README
/usr/share/man/man1/lpr.1.gz
/usr/share/man/man1/winln.1.gz
/etc/postinstall/cygutils.sh
/usr/share/applications/cygstart.desktop
/usr/share/mime/packages/cygutils.xml

--
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: Cygwin64: mkshortcut - Segmentation fault

2013-06-07 Thread Charles Wilson

On 6/7/2013 8:35 AM, Vasiliy wrote:

$ /usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bin/run.exe
   4 [main] mkshortcut (9880) C:\cygwin64\bin\mkshortcut.exe: ***
fatal error - cygheap base mismatch detected - 0x0/0x61272950.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.
Segmentation fault


Unfortunately, this is not a problem, per se, within mkshortcut itself. 
It's a system issue; make sure there are no other cygwin1.dll's on your 
system or in your $PATH.  Finally, you could try manually running 
rebaseall in your 64bit installation, and then rebooting.


--
Chuck



--
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] Updated: Cygwin 1.7.19

2013-06-07 Thread Nick Lowe
> Nick, was it you, who wrote this article?
> http://www.nicklowe.org/2012/02/understanding-case-sensitivity-in-windows-obcaseinsensitive-file_case_sensitive_search/
> Thanks for it, if so.
> But the more frustrating it makes your post, as article clearly states, that

I did, yes. I was trying to get my head around it and the design a
year or so ago and decided to document it as I could find nothing
substantive available on the Web.

At the time, I noticed that Corinna special cased Windows 2000 to keep
reading obcaseinsensitive in the patch that was otherwise committed to
test for the actual state of case sensitivity instead:

http://cygwin.com/ml/cygwin-cvs/2012-q1/msg00115.html

It is a mess and pretty frustrating! You have to be very careful about
the assumptions that you make in your code.

Regards,

Nick

--
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



Fwd: Cygwin64: mkshortcut - Segmentation fault

2013-06-07 Thread Vasiliy
Please, check/note:
> libcygicons.dll.a < is being *installed* to /usr/lib from the sources instead 
> of > libicons.dll.a < compiled (!)

Best,
Vasiliy


-- Forwarded message --
From: Vasiliy
Date: Fri, Jun 7, 2013 at 2:35 PM
Subject: Cygwin64: mkshortcut - Segmentation fault
To: cygwin dot cygwin 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: [ANNOUNCEMENT] Updated: Cygwin 1.7.19

2013-06-07 Thread Nick Lowe
I do not think I explained myself properly, sorry: Cygwin would
previously read the
obcaseinsensitve value under Windows 2000 to emulate the case
insensitive behaviour of Windows XP and newer where obcaseinsensitive
was present in the registry.

The registry key does not represent the active state of case
sensitivity, so it is surely the wrong thing to query and show in
cygcheck as it only shows what the state is pending a reboot. Surely
it would be better now to query how the case sensitivity actually is
here and show that, and get rid of all references to
obcaseinsensitive, which is a configuration parameter and private
implementation detail of kernel?

Regards,

Nick

--
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] Updated: Cygwin 1.7.19

2013-06-07 Thread Andrey Repin
Greetings, Nick Lowe!

> I notice you are still reading in obcaseinsensitive in cygcheck.cc but
> this value is no longer used in Cygwin as you have dropped Windows
> 2000 support.

> Would it make sense to change the code there to show the actual state
> of case sensitivity?

Nick, was it you, who wrote this article?
http://www.nicklowe.org/2012/02/understanding-case-sensitivity-in-windows-obcaseinsensitive-file_case_sensitive_search/
Thanks for it, if so.
But the more frustrating it makes your post, as article clearly states, that

> It turns out that there are two parts to this. Firstly, a single setting
> that controls case sensitivity on system-wide basis, obcaseinsensitive, and
> then, assuming that case sensitive operation is supported, file system
> support on a per-volume basis.


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 07.06.2013, <17:03>

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



Cygwin64: mkshortcut - Segmentation fault

2013-06-07 Thread Vasiliy
Original suspect:

user@host /etc/postinstall
$ cat /etc/postinstall/xinit.sh
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X"
/usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bin/run.exe

user@host /etc/postinstall
$ env V=2 VERBOSE=2 xinit.sh
./xinit.sh: line 2: 22136 Aborted (core dumped)
/usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bin/run.exe

Real cause:

user@host /etc/postinstall
$ /usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X"

user@host /etc/postinstall
$ /usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bin/run.exe
Aborted (core dumped)

$ cygcheck -f /usr/bin/mkshortcut.exe
cygutils-1.4.12-1

$ /bin/tar -C/ -jxvf cygutils-1.4.12-2.tar.bz2
usr/bin/cygstart.exe
usr/bin/mkshortcut.exe
usr/bin/readshortcut.exe
usr/share/man/man1/cygstart.1.gz
usr/share/man/man1/mkshortcut.1.gz
usr/share/man/man1/readshortcut.1.gz

???:
$ cygcheck -f /usr/bin/mkshortcut.exe
cygutils-1.4.12-1

$ /usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X"

$ /usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bin/run.exe
  4 [main] mkshortcut (9880) C:\cygwin64\bin\mkshortcut.exe: ***
fatal error - cygheap base mismatch detected - 0x0/0x61272950.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.
Segmentation fault

$ uname -a
CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64 Cygwin

--
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] Updated: Cygwin 1.7.19

2013-06-07 Thread Corinna Vinschen
Hi Nick,

On Jun  7 12:00, Nick Lowe wrote:
> Hi Corinna,
> 
> I notice you are still reading in obcaseinsensitive in cygcheck.cc but
> this value is no longer used in Cygwin as you have dropped Windows
> 2000 support.
> 
> Would it make sense to change the code there to show the actual state
> of case sensitivity?

You have that upside down.  The obcaseinsensitive registry key has been
introduced with Windows XP, and it's set to 1 by default, unfortunately.
So it's important to know this value starting with XP.  Windows 2000 was
never affected.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
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] Updated: Cygwin 1.7.19

2013-06-07 Thread Nick Lowe
Hi Corinna,

I notice you are still reading in obcaseinsensitive in cygcheck.cc but
this value is no longer used in Cygwin as you have dropped Windows
2000 support.

Would it make sense to change the code there to show the actual state
of case sensitivity?

Kind regards,

Nick

--
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: ASLR breaks cygwin

2013-06-07 Thread Eliot Moss

On 6/7/2013 3:56 AM, Corinna Vinschen wrote:


Hell would sooner freeze over.



So I should put away my ice-skates and pitchforks?  Wait, was that
a pun? ;-)



Sorry, I don't get the ice-skates pun.


Ice-skates for a frozen place place, pitchforks for hell 

Regards - Eliot Moss

--
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



[ANNOUNCEMENT] Updated: Cygwin 1.7.20

2013-06-07 Thread Corinna Vinschen
Hi Cygwin friends and users,


I just released Cygwin 1.7.20.  It only contains a single bug fix
compared to 1.7.19 to avoid a hang:

- Fix starvation problem when handling SIGCONT.
  Fixes: http://cygwin.com/ml/cygwin/2013-06/msg00084.html


Have fun,
Corinna


    *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: [TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)

2013-06-07 Thread Corinna Vinschen
On Jun  6 12:58, Warren Young wrote:
> On 6/6/2013 11:22, Corinna Vinschen wrote:
> >
> >The lazy unlock request D tells the system to unlock all locks on the
> >entire file.  This works fine with POSIX locks, but it does not work
> >with Windows locks.  These require to unlock a lock exactly as it has
> >been created.
> 
> I wouldn't be upset if you decided that was grounds for removing the
> code that tries to support mandatory locking for POSIX locks.  As
> far as I'm concerned, this is very much an experimental feature, and
> experiments often fail.  The failure already told us what to try
> next (BSD locks) and according to the one report received so far, it
> looks like it might fix it.

Well, after all it's still record locking, so it's kind of weird to
support a flock-like file lock but no record locks.  If an application
uses this carefully with Windows semantics in mind, it might even be
useful.

However, what's missing in the long run is documentation.  I'm just
about to add a few words to the docs.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
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: ASLR breaks cygwin

2013-06-07 Thread Corinna Vinschen
On Jun  6 15:43, Larry Hall (Cygwin) wrote:
> On 6/6/2013 1:27 PM, Corinna Vinschen wrote:
> >On Jun  6 11:06, Warren Young wrote:
> >>On 6/6/2013 10:52, Dan Kegel wrote:
> >>>
> >>>I wonder if we could get them to recognize the parent-child
> >>>relationship somehow, and keep the same address space
> >>>in the child.
> >>>
> >>>Just kidding.   Hell would sooner freeze over.
> >>
> >>I don't know about that.  For a long time, they had a bigger
> >>conflict of interest with Cygwin due to SFU/SUA/Interix and the
> >>POSIX subsystem. They announced SUA's doom a couple of years ago[1]
> >>and the need for a separate native POSIX API is gone[2].  I even
> >>recall reading on this list that Microsoft now recommends Cygwin, at
> >>least unofficially.
> >>
> >>Perhaps Microsoft now has some incentive to create a native fork(2)
> >>like call in their OS that Cygwin could use.  (Or something close
> >>enough, like Linux's clone(2).)
> >
> >The problem is not the call.  Such a call exists, since Vista even
> >one with very simple usage.  The problem is that this call has
> >been created for SUA, and some Win32 libs as well as the console
> >subsystem don't work with this call because there never have been
> >made provisions for a fork call in the Win32 libs.  Chances for
> >a change are rather low.
> 
> So I should put away my ice-skates and pitchforks?  Wait, was that
> a pun? ;-)

Sorry, I don't get the ice-skates pun.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

--
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