Re: Why package cache is not used during setup download?

[Aleksey Midenkov]

On Mon, Oct 26, 2015 at 2:48 PM, Andrey Repin  wrote:
> Greetings, Aleksey Midenkov!
>
 Cygwin setup process my turn to endless retry-error on bad internet
 channels, because:
>>>
 1. setup doesn't know how to retry download (why it fails to download 
 anyway?);
>>>
>>> Because your internet is bad?
>
>> On the second thought I believe that the problem is with setup.exe
>> itself. Because:
>
>> a) I tried different mirrors. It always fails in somewhere between
>> 80-90% (of total progress).
>> b) I never noticed any problems with downloading files except with
>> Cygwin. Gigabyte-sized files via http are downloading without fail.
>
> If you get consistent results from different mirrors (and since you're the
> only person reporting it), my second thought is that it is a local issue.
> Overly zealous antivirus/firewall coming to mind.

I remember this was also happening long time ago (about 10 years or
more) in completely different environment of course. Anyway, local
problem with *Cygwin-only* means problem with Cygwin. I rarely use
Cygwin and when I use it, I always stumble upon this. Maybe there is
another reason of why you don't know of other complaints.

>
 2. setup doesn't use cache of previously downloaded files and always
 redownload all packages from the beginning.
>>>
>>> It do use cache, if checksum is correct.
>
>> Hmmm, on setup.ini doc says:
>
>> install: filename size-in-bytes MD5 sum
>
> As David pointed out already, MD5 hash proven weak and is no longer used in
> sensitive environments.

I don't need to know who the David is and what he pointed out. But
what does this mean in core, the documentation is wrong and checksum
is done with different algorithm?

>
>
> --
> With best regards,
> Andrey Repin
> Monday, October 26, 2015 14:45:39
>
> 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: Bash unable to print epoch timestamp

[Corinna Vinschen]

On Oct 26 19:16, Brian Inglis wrote:
> On 2015-10-26 11:34, Brian Inglis wrote:
> >Third time lucky - pasting inline into email and resending to all previous 
> >lists.
> >
> >Please note that conversion into too-small buffer size in regression test 
> >may not have expected result!
> >
> >Tried to build with below and variants:
> >gcc -D_REGRESSION_TEST -D_COMPILING_NEWLIB -Dsniprintf=snprintf 
> >-I/usr/src/cygwin-2.2.1-1.src/newlib-cygwin/winsup/cygwin/include -o 
> >strftime-s-test strftime.c
> >gives undef refs for __cygwin_gettzname, __cygwin_gettzoffset, 
> >__get_current_time_locale, __tz_lock, __tz_unlock,
> >_tzset_unlocked
> >
> >Build stc with std cmdline and current strftime works and does demo issue.
> 
> Sorry - redo with the file existing!

No worries, I applied your other patch since it also cleaned up some
whitespaces and, for some reason, the below patch didn't apply cleanly.

There was just one problem:

> +   {
> + long offset;/* offset < 0 => W of GMT, > 0 => E of GMT:
> + offset = 0;subtract to get UTC */

This setting the offset to 0 is necessary, but commented out.  Typo?
I fixed this before committing the patch.


Thanks again,
Corinna

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


pgpN7qDBa9ixd.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Corinna Vinschen]

On Oct 26 17:03, Achim Gratz wrote:
> Am 26.10.2015 um 11:07 schrieb Corinna Vinschen:
> >Erm, really?  I tested this locally with a directory with hundreds
> >of files, each of which belonged to another user or group, and that
> >resulted in a 25% slowdown.  Not 1000%.  Oh boy.
> 
> That test is almost as bad as it can ever get.  Given that enumerating all
> AD accouts with mkpasswd takes about 2 hours and I'm doing something very
> similar here, I'm not even surprised.  I was more surprised to see the
> server go so fast, but my guess is that it can use jumbo frames to talk to
> the AD.

Ok, so you don't seem to think this is a major drawback.

> >>While that hurts, the more usual case with many files from the
> >>same user doesn't feel any slower at the moment.  The access through VPN
> >>will be interesting, though...
> >
> >Did you try this in the meantime?
> 
> No, sorry.

No worries.  I'm mulling over the idea to release 2.3.0 this week
without the new ACL handling code to get the latest fixes out of the
door first and push this stuff into a 2.4.0 release in November.

> >Given the above result, I'm wondering if we can afford using AuthZ at
> >all.  OTOH I don't see any other way to get the correct POSIX permissions
> >from a non-Cygwin ACL :(
> 
> If you really want fast but incorrect there's always the "noacl" mount
> option.

Right.  OTOH, maybe we could enhance the "acl" mount option?

"acl" -> "quickacl" -> "noacl"?


> -- 
> Achim.
> 
> (on the road :-)

https://www.youtube.com/watch?v=qRKNw477onU


Corinna

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


pgpO0WoeU8GvR.pgp
Description: PGP signature

Re: problems with to_string not declared in this scope

[Corinna Vinschen]

On Oct 26 17:04, Achim Gratz wrote:
> Am 26.10.2015 um 11:36 schrieb Corinna Vinschen:
> >It would still be nice if somebody with a bit of math knowledge would
> >contribute the missing long double functions to newlib.
> 
> Or switch to musl?

Easier said than done.  The integration with newlib is pretty tight.
Maybe we can use their long double math funcs?


Corinna

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


pgpP2v5nLoPnQ.pgp
Description: PGP signature

Re: pthread_kill: signals remain pending after target thread exits

[Corinna Vinschen]

John?  Ping?

On Oct 23 14:55, Corinna Vinschen wrote:
> On Oct 22 02:08, John Carey wrote:
> > > From: Corinna Vinschen [corinna-cyg...@cygwin.com]
> > > Sent: Wednesday, October 21, 2015 4:48 AM
> > > Subject: Re: pthread_kill: signals remain pending after target thread 
> > > exits
> > ...
> > > > On Sep 11 18:11, John Carey wrote:
> > > > There seems to be a problem with pthread_kill: a pending signal
> > > > targeting a particular thread prevents other threads from receiving
> > > > signals sharing the same signal number--even after the original target
> > > > thread exits and is joined.
> > ...
> > > The important thing here is to get rid of the pending signal.
> > 
> > Yes, I agree that is the most important thing.
> > 
> > > > In my view it would be desirable if:
> > > >
> > > >   - Pending signals targeting a particular thread would not outlast
> > > >   that thread.
> > > 
> > > Since you looked into the code anyway, do you have an idea how to
> > > implement that?  For a start, do you have a simple testcase, only
> > > the bare code needed to reproduce the issue?
> > 
> > I've attached a test case that I *think* gets into the right spot, at
> > least for 64-bit Cygwin 2.0.4.  That is, it hangs trying to receive
> > the signal, instead of terminating.  (This test passes (terminates) in
> > 32-bit Cygwin 1.7.9 and 64-bit Ubuntu 14.04.3 LTS.)
> 
> Thanks for the testcase.  I applied a patch which hopefully works as
> desired, at least to fix the immediate problem of the remaining pending
> signal when a thread exits.  I uploaded a new developer snapshot to
> https://cygwin.com/snapshots.  Please give it a try.
> 
> Note that the today's snapshot does *NOT* contain the changes concerning
> the new ACL handling, so people testing that stuff should skip this
> snapshot.
> 
> > > >   - Multiple pending signals targeting different threads could
> > > >   coexist, even if they shared the same signal number.  This happens
> > > >   on Linux (Ubuntu 14.04.3), where I can generate two signals for two
> > > >   different threads, then sleep for a bit in each target thread, and
> > > >   finally have each thread receive its signal with sigwait()--neither
> > > >   signal is lost during the sleeping period.
> > > 
> > > That requires to extend the handling for pending signals.  That's
> > > a rather bigger task...
> > 
> > Yeah.  It's nice if threads don't interfere with each other, but this
> > part would indeed be harder to change.
> 
> I added that to my neverending TODO list.  Maybe I get around to it at
> one point.
> 
> 
> Thanks,
> Corinna

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


pgp1YsBhQzmlx.pgp
Description: PGP signature

Re: gawk: Bad File Descriptor error with concurrent readonly access to a network file

[Corinna Vinschen]

On Sep 25 16:31, Vermessung AVT - Wolfgang Rieger wrote:
> 1) Concurrent read access to the setup files was possible and worked
> fine with local files (24 hrs testing with millions of file accesses
> in 4 parallel jobs).
> 2) However, when the file to be read (datafile.txt) is stored on a
> network share on a file server - which is the case in our working
> environment - the error could be reproduced. The number of Bad file
> descriptor errors seems to be related to the work load at the server
> where the file resides.
> 3) The MS copy command shows no such error, even with network files.
> So we can substitute the cat's by copy's. For gawk, however, there is
> no shell alternative.
> 
> It looks like there is a small time frame in opening files when the
> server file is non-accessible to other processes. If a parallel job
> happens to access the same file within that short time period while
> another process is opening it, the "Bad File Descriptor" error is
> thrown.

Cygwin uses full sharing for all files it opens, unless the file is
opened in very specific circumstances (e.g, creating a symlink, deleting
a file).  "Bad file descriptor" doesn't point to a sharing problem.
It seems the handle is unusable or something.

I tried your testcase and I can't reproduce the problem in my
environment.  Have you tried catching a trace of the problem via
strace?  It would be helpful to see where the EBADF occurs.


Corinna

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


pgpm0D9bORlvC.pgp
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4

[Achim Gratz]

Am 27.10.2015 um 10:27 schrieb Corinna Vinschen:

That test is almost as bad as it can ever get.  Given that enumerating all
AD accouts with mkpasswd takes about 2 hours and I'm doing something very
similar here, I'm not even surprised.  I was more surprised to see the
server go so fast, but my guess is that it can use jumbo frames to talk to
the AD.


Ok, so you don't seem to think this is a major drawback.


I didn't say I would not like to see it run faster.  But considering the 
alternatives, working correctly all the times at the current speed seems 
to cover my more typical uses a lot better.



No worries.  I'm mulling over the idea to release 2.3.0 this week
without the new ACL handling code to get the latest fixes out of the
door first and push this stuff into a 2.4.0 release in November.


As long as you keep reminding us which snapshot has the new ACL handling 
code, that is OK with me.  I will want to push out the snapshot in a 
week or two and remove some of my workarounds for ACL corrections and/or 
noacl mounted directories in order to see if these things are working 
now for real.



Given the above result, I'm wondering if we can afford using AuthZ at
all.  OTOH I don't see any other way to get the correct POSIX permissions

>from a non-Cygwin ACL :(

If you really want fast but incorrect there's always the "noacl" mount
option.


Right.  OTOH, maybe we could enhance the "acl" mount option?

"acl" -> "quickacl" -> "noacl"?


Let's worry about that middle ground scenario when the ACL code has 
proven itself.  The danger here is that the edge cases that will make 
problems are not easy to spot before you run into them


--
Achim.

(on the road :-)


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

[Corinna Vinschen]

On Oct 27 10:53, Achim Gratz wrote:
> Am 27.10.2015 um 10:27 schrieb Corinna Vinschen:
> >>That test is almost as bad as it can ever get.  Given that enumerating all
> >>AD accouts with mkpasswd takes about 2 hours and I'm doing something very
> >>similar here, I'm not even surprised.  I was more surprised to see the
> >>server go so fast, but my guess is that it can use jumbo frames to talk to
> >>the AD.
> >
> >Ok, so you don't seem to think this is a major drawback.
> 
> I didn't say I would not like to see it run faster.

Me neither.  No wonder Windows largely skips showing effective
permissions unless explicitely requested by the user.

> But considering the
> alternatives, working correctly all the times at the current speed seems to
> cover my more typical uses a lot better.

Ok.

> >No worries.  I'm mulling over the idea to release 2.3.0 this week
> >without the new ACL handling code to get the latest fixes out of the
> >door first and push this stuff into a 2.4.0 release in November.
> 
> As long as you keep reminding us which snapshot has the new ACL handling
> code, that is OK with me.

I guess you should better use the latest test releases, which I'll
always build with the new ACL handling.  The snapshots are rather for
quick&dirty testing the latest changes.

> I will want to push out the snapshot in a week or
> two and remove some of my workarounds for ACL corrections and/or noacl
> mounted directories in order to see if these things are working now for
> real.

Cool.  I'm looking forward to it.

> >>>Given the above result, I'm wondering if we can afford using AuthZ at
> >>>all.  OTOH I don't see any other way to get the correct POSIX permissions
> >>>from a non-Cygwin ACL :(
> >>
> >>If you really want fast but incorrect there's always the "noacl" mount
> >>option.
> >
> >Right.  OTOH, maybe we could enhance the "acl" mount option?
> >
> >"acl" -> "quickacl" -> "noacl"?
> 
> Let's worry about that middle ground scenario when the ACL code has proven
> itself.  The danger here is that the edge cases that will make problems are
> not easy to spot before you run into them

Good point.


Corinna

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


pgpkGgOyyiDjx.pgp
Description: PGP signature

Re: gawk: Bad File Descriptor error with concurrent readonly access to a network file

[Matt D.]

I haven't had an opportunity to look into it but I've also encountered 
errors when performing a parallel make build (make -j) on a large C++ 
project which has multiple interdependencies across a network share with 
too many threads.


The reported "Bad File Descriptor" is the same error that I get.

Matt D.

On 10/27/2015 5:52 AM, Corinna Vinschen wrote:

On Sep 25 16:31, Vermessung AVT - Wolfgang Rieger wrote:

1) Concurrent read access to the setup files was possible and worked
fine with local files (24 hrs testing with millions of file accesses
in 4 parallel jobs).
2) However, when the file to be read (datafile.txt) is stored on a
network share on a file server - which is the case in our working
environment - the error could be reproduced. The number of Bad file
descriptor errors seems to be related to the work load at the server
where the file resides.
3) The MS copy command shows no such error, even with network files.
So we can substitute the cat's by copy's. For gawk, however, there is
no shell alternative.

It looks like there is a small time frame in opening files when the
server file is non-accessible to other processes. If a parallel job
happens to access the same file within that short time period while
another process is opening it, the "Bad File Descriptor" error is
thrown.


Cygwin uses full sharing for all files it opens, unless the file is
opened in very specific circumstances (e.g, creating a symlink, deleting
a file).  "Bad file descriptor" doesn't point to a sharing problem.
It seems the handle is unusable or something.

I tried your testcase and I can't reproduce the problem in my
environment.  Have you tried catching a trace of the problem via
strace?  It would be helpful to see where the EBADF occurs.


Corinna



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

Setup.exe version 2.873 (64 bits)

[André B . Derraik]

Hi,
I got a setup problem when using proxy.

Setup.exe version 2.873 (64 bits)
Proxy problem.
On page "Select Your Internet Connection", if you choose the option "Use 
Internet Explorer Proxy Settings", the program stucks when trying to download 
the control files (setup.bz2.sig, ...).
I use this option by a long time and never had a problem, even when I dont´t set 
a proxy for the system (is the almost time). I use this when I need to go some 
clients.


Abraços.

André B. Derraik
Consultor
Instituto Tecgraf/PUC-Rio  http://www.tecgraf.puc-rio.br
an...@tecgraf.puc-rio.br  Tel.: +55-21-3520-4411/4412



--
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: initial cygwin installation

[Nellis, Kenneth]

From: Warren Young
> 
> On Oct 25, 2015, at 3:11 PM, t s  wrote:
> >
> > Q: How do I install everything?
> > A: You do not want to do this!
> 
> I explain this in more detail here:
> 
>   http://stackoverflow.com/a/21233990

For the hell of it I decided to check out this hidden feature.
What I got was two dialog boxes popping up talking about
Cygwin limitations, something about "this port of Avahi",
references to Apple's "Bounjour mDNSResponder" service,
and a link to http://support.apple.com/kb/DL999.

What's up with that?

--Ken Nellis

--
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: gawk: Bad File Descriptor error with concurrent readonly access to a network file

[Corinna Vinschen]

On Oct 27 06:48, Matt D. wrote:
> I haven't had an opportunity to look into it but I've also encountered
> errors when performing a parallel make build (make -j) on a large C++
> project which has multiple interdependencies across a network share with too
> many threads.
> 
> The reported "Bad File Descriptor" is the same error that I get.

That's fine and all, but it doesn't add any new info to the case.

> 
> Matt D.
> 
> On 10/27/2015 5:52 AM, Corinna Vinschen wrote:
> >On Sep 25 16:31, Vermessung AVT - Wolfgang Rieger wrote:
> >>1) Concurrent read access to the setup files was possible and worked
> >>fine with local files (24 hrs testing with millions of file accesses
> >>in 4 parallel jobs).
> >>2) However, when the file to be read (datafile.txt) is stored on a
> >>network share on a file server - which is the case in our working
> >>environment - the error could be reproduced. The number of Bad file
> >>descriptor errors seems to be related to the work load at the server
> >>where the file resides.
> >>3) The MS copy command shows no such error, even with network files.
> >>So we can substitute the cat's by copy's. For gawk, however, there is
> >>no shell alternative.
> >>
> >>It looks like there is a small time frame in opening files when the
> >>server file is non-accessible to other processes. If a parallel job
> >>happens to access the same file within that short time period while
> >>another process is opening it, the "Bad File Descriptor" error is
> >>thrown.
> >
> >Cygwin uses full sharing for all files it opens, unless the file is
> >opened in very specific circumstances (e.g, creating a symlink, deleting
> >a file).  "Bad file descriptor" doesn't point to a sharing problem.
> >It seems the handle is unusable or something.
> >
> >I tried your testcase and I can't reproduce the problem in my
> >environment.  Have you tried catching a trace of the problem via
> >strace?  It would be helpful to see where the EBADF occurs.

I'm running the testscript for a few hours now, with a server under heavy
load, but I still can't reproduce it.

Is this a bad interaction with some virus scanner, perhaps?


Corinna

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


pgpUGYvePb1eR.pgp
Description: PGP signature

Re: Command line length in Ash or Dash Shells

[Dr Rainer Woitok]

Eric,

On Monday, 2015-10-26 10:14:06 -0600, you wrote:

> ...
>  So once
> you start a dash shell, that dash shell can start any number of other
> dash shells with no command line length limit other than the memory
> available to your machine.

Assume I terminate  Cygserver and any  other Cygwin  services running, I
then start "ash.exe" by double clicking it in a Windows Explorer window,
from the  command line  in the  "ash.exe"  window  I start my  Ash Shell
script which in turn starts  "setup-x86*.exe"  with a  very long command
line.

Am I interpreting you correctly in assuming that under these circumstan-
ces the maximum length of this command line  is 2 * 10**9 ASCII charact-
ers on my box?

This would be just enough I think.

Sincerely,
  Rainer

--
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: Command line length in Ash or Dash Shells

[Corinna Vinschen]

On Oct 27 16:10, Dr Rainer Woitok wrote:
> Eric,
> 
> On Monday, 2015-10-26 10:14:06 -0600, you wrote:
> 
> > ...
> >  So once
> > you start a dash shell, that dash shell can start any number of other
> > dash shells with no command line length limit other than the memory
> > available to your machine.
> 
> Assume I terminate  Cygserver and any  other Cygwin  services running, I
> then start "ash.exe" by double clicking it in a Windows Explorer window,
> from the  command line  in the  "ash.exe"  window  I start my  Ash Shell
> script which in turn starts  "setup-x86*.exe"  with a  very long command
> line.
> 
> Am I interpreting you correctly in assuming that under these circumstan-
> ces the maximum length of this command line  is 2 * 10**9 ASCII charact-
> ers on my box?

That won't work.  setup.exe is a non-Cygwin application so it's restricted
to the maximum line length of the CreateProcess call, which, per
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
is 32768 characters.


Corinna

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


pgpaShj5xc8sz.pgp
Description: PGP signature

Re: Command line length in Ash or Dash Shells

[Dr Rainer Woitok]

Corinna,

On Tuesday, 2015-10-27 16:17:56 +0100, you wrote:

> ...
> That won't work.  setup.exe is a non-Cygwin application so it's restricted
> to the maximum line length of the CreateProcess call, which, per
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
> is 32768 characters.

Thanks for clarifying :-)

Sincerely,
  Rainer

--
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: Command line length in Ash or Dash Shells

[Eric Blake]

On 10/27/2015 09:10 AM, Dr Rainer Woitok wrote:
> Eric,
> 
> On Monday, 2015-10-26 10:14:06 -0600, you wrote:
> 
>> ...
>>  So once
>> you start a dash shell, that dash shell can start any number of other
>> dash shells with no command line length limit other than the memory
>> available to your machine.
> 
> Assume I terminate  Cygserver and any  other Cygwin  services running, I
> then start "ash.exe" by double clicking it in a Windows Explorer window,
> from the  command line  in the  "ash.exe"  window  I start my  Ash Shell
> script which in turn starts  "setup-x86*.exe"  with a  very long command
> line.

Sadly, setup-x86*.exe is a native Windows process, not a cygwin process
(and MUST be, since you can run setup prior to having cygwin installed).
 So it is unfortunately stuck at the Windows limitations on max
command-line+environment sizing.

Of course, patches are welcome, if someone would like to propose a way
to make setup-x86.exe read its package list from a file name given on
the command line, rather than having to pass every package name on the
command line.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

How can I completely remove Perl 5.22?

[Jim Reisert AD1C]

Hi,

I am having some problems trying to make ActiveState Perl and Cygwin
Perl 5.22 co-exist.  I currently have a Perl program that uses the Tk
library, which I am unable to compile using the ActiveState PDK.  I am
pretty sure it was working before I upgraded Cygwin Perl to version
5.22.  My current thinking is to backtrack to Cygwin Perl 5.14 and see
if I can make the two co-habitate again.

Other than un-installing Cygwin Perl, how can I ensure that all CPAN
and/or compiled libraries/modules are also removed (most likely in my
Cygwin home directory)?  I realize that parts of Perl are needed for
the Cygwin base install.

These are the Cygwin packages that I have installed, that have the
word "perl" in them:

* perl
* perl_autorebase
* perl_base

Thanks - Jim

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
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: How can I completely remove Perl 5.22?

[Achim Gratz]

Am 27.10.2015 um 18:49 schrieb Jim Reisert AD1C:

I am having some problems trying to make ActiveState Perl and Cygwin
Perl 5.22 co-exist.


If they did so in the past, I see no reason why they shouldn't continue 
to do so.



I currently have a Perl program that uses the Tk
library, which I am unable to compile using the ActiveState PDK.  I am
pretty sure it was working before I upgraded Cygwin Perl to version
5.22.  My current thinking is to backtrack to Cygwin Perl 5.14 and see
if I can make the two co-habitate again.


I would guess that is merely a temporal coincidence.


Other than un-installing Cygwin Perl, how can I ensure that all CPAN
and/or compiled libraries/modules are also removed (most likely in my
Cygwin home directory)?


Unless you've actively subverted it, Perl knows to keep it's stuff 
separate from other versions of Perl that may happen to be installed on 
the same machine.


You may have an issue with the search order in PATH, though.


I realize that parts of Perl are needed for
the Cygwin base install.


No, not yet.


These are the Cygwin packages that I have installed, that have the
word "perl" in them:

* perl
* perl_autorebase
* perl_base


None of these packages install anything into your home directory.


--
Achim.

(on the road :-)


--
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_kill: signals remain pending after target thread exits

[John Carey]

Sorry for the delay.

From: Corinna Vinschen [corinna-cyg...@cygwin.com]
Sent: Friday, October 23, 2015 5:55 AM
> > I've attached a test case that I *think* gets into the right spot, at
> > least for 64-bit Cygwin 2.0.4.  That is, it hangs trying to receive
> > the signal, instead of terminating.  (This test passes (terminates) in
> > 32-bit Cygwin 1.7.9 and 64-bit Ubuntu 14.04.3 LTS.)
> 
> Thanks for the testcase.  I applied a patch which hopefully works as
> desired, at least to fix the immediate problem of the remaining pending
> signal when a thread exits.  I uploaded a new developer snapshot to
> https://cygwin.com/snapshots.  Please give it a try.

Thanks; that was fast!  I tried replacing cygwin1.dll with cygwin1-20151023.dll 
.

The original test case now works.  I checked some of my other tests,
and unfortunately some of them failed, so I extracted out a new test
case, which is attached.  My guess is that something is subtly different
about the timing on this test.

This new test hangs about half the time, and I have to use Windows Task Manager
to kill it (not Cygwin "kill"). Sometimes I see "pthread_kill: Unknown error 
-1" while
it hangs (meaning that pthread_kill returned -1 instead of an error number).

> > > >   - Multiple pending signals targeting different threads could
> > > >   coexist, even if they shared the same signal number.  This happens
> > > >   on Linux (Ubuntu 14.04.3), where I can generate two signals for two
> > > >   different threads, then sleep for a bit in each target thread, and
> > > >   finally have each thread receive its signal with sigwait()--neither
> > > >   signal is lost during the sleeping period.
> > >
> > > That requires to extend the handling for pending signals.  That's
> > > a rather bigger task...
> >
> > Yeah.  It's nice if threads don't interfere with each other, but this
> > part would indeed be harder to change.
> 
> I added that to my neverending TODO list.  Maybe I get around to it at
> one point.

I know the feeling.  No worries, and thanks.

-- John Carey
/* Copyright (c) 2015, Electric Cloud, Inc.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 *   - Redistributions of source code must retain the above copyright
 * notice, this list of conditions and the following disclaimer.
 *
 *   - Redistributions in binary form must reproduce the above copyright
 * notice, this list of conditions and the following disclaimer in the
 * documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/* This test program demonstates a Cygwin bug in which a signal sent
 * to a particular thread remains pending after the thread terminates.
 *
 * Somehow even though the original fix worked for test_pending_signal.c,
 * about half the time this test case triggers a hang that must be killed
 * using the Windows Task Manager instead of Cygwin "kill".  Sometimes we
 * see "pthread_kill: Unknown error -1" during the hang.
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


static void check_syscall(char const *context, int result)
{
if (result == -1) {
fprintf(stderr, "%s: %s\n", context, strerror(errno));
exit(EXIT_FAILURE);
}
}

static void check_threadcall(char const *context, int error_number)
{
if (error_number) {
fprintf(stderr, "%s: %s\n", context, strerror(error_number));
exit(EXIT_FAILURE);
}
}


typedef struct shared_struct {
sigset_t signal_mask;  /* signals to block */
pthread_mutex_t mutex;
pthread_cond_t cond;
int eat;
int done;
} shared_t;


static void *phage_thread (void *arg)
{
shared_t *shared = (shared_t *)arg;

check_threadcall("pthread_mutex_lock",
pthread_mutex_lock(&shared->mutex));

if (shared->eat <= 1) {
shared->eat = 1;
check_threadcall("pthread_cond_broadcast",
pthread_cond_broadcast(&shared->cond));

while (shared->eat <= 1) {
check_threadcall("pthread_cond_wait",
pthread_cond_wait(&shared->cond, &shared->mutex));

Re: gawk: Bad File Descriptor error with concurrent readonly access to a network file

[Vermessung AVT - Wolfgang Rieger]

From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com]
Sent: Tuesday, October 27, 2015 10:53
To: cygwin@cygwin.com
Subject: Re: gawk: Bad File Descriptor error with concurrent readonly access to 
a network file
 (Snip)
> Cygwin uses full sharing for all files it opens, unless the file is opened in 
> very specific circumstances (e.g, creating a symlink,
> deleting a file).  "Bad file descriptor" doesn't point to a sharing problem.
> It seems the handle is unusable or something.
>
> I tried your testcase and I can't reproduce the problem in my environment.
> Have you tried catching a trace of the problem via strace?
> It would be helpful to see where the EBADF occurs.

Here is the portion of strace output where IMHO the error occurs. The behaviour 
is quite different when running with strace, so I hope it is the same error 
situation, but at least the message given is "Bad file descriptor".
I changed the paths to ???. This is strace --mask=syscall. If you need further 
info I would appreciate to send it directly to you since there is a lot of info 
in strace I do not want to put into the www:

  197   70416 [main] gawk 3844 open: 3 = open(???\datafile.txt, 0x8000)
  327   70743 [main] gawk 3844 fcntl64: 0 = fcntl(3, 1, 0x0)
  265   71008 [main] gawk 3844 fcntl64: 0 = fcntl(3, 2, 0x1)
 3298   74306 [main] gawk 3844 fhandler_base::fstat_helper: 0 = fstat 
(\??\???\datafile.txt, 0x8004AEF8) st_size=135, st_mode=0100644, 
st_ino=281474976912276st_atim=551A9D6D.BD48F54 st_ctim=5603C3F5.26F49798 
st_mtim=54E1ECAE.B2A66C8 st_birthtim=551A9D6D.BD48F54
  206   74512 [main] gawk 3844 fstat64: 0 = fstat(3, 0x8004AEF8)
  216   74728 [main] gawk 3844 isatty: 0 = isatty(3)
 1887   76615 [main] gawk 3844 fhandler_base::fstat_helper: 0 = fstat 
(\??\???\datafile.txt, 0x8004AEF8) st_size=135, st_mode=0100644, 
st_ino=281474976912276st_atim=551A9D6D.BD48F54 st_ctim=5603C3F5.26F49798 
st_mtim=54E1ECAE.B2A66C8 st_birthtim=551A9D6D.BD48F54
  241   76856 [main] gawk 3844 fstat64: 0 = fstat(3, 0x8004AEF8)
  304   77160 [main] gawk 3844 read: read(3, 0x8004AF90, 135) blocking
 1722   78882 [main] gawk 3844 seterrno_from_nt_status: 
/home/corinna/src/cygwin/cygwin-1.7.33/cygwin-1.7.33-1.i686/src/src/winsup/cygwin/fhandler.cc:276
 status 0xC128 -> windows error 6
  210   79092 [main] gawk 3844 geterrno_from_win_error: windows error 6 == 
errno 9
  170   79262 [main] gawk 3844 read: -1 = read(3, 0x8004AF90, -1), errno 9

A successful call goes on after the "read: read(3, ..., 135)" like this:
  129  187614 [main] gawk 4452 fhandler_base::read: returning 135, text mode
  147  187761 [main] gawk 4452 read: 135 = read(3, 0x8004AF80, 135)
  181  187942 [main] gawk 4452 read: read(3, 0x8004AF80, 135) blocking
  130  188072 [main] gawk 4452 fhandler_base::read: returning 0, text mode
  150  188222 [main] gawk 4452 read: 0 = read(3, 0x8004AF80, 0)
  350  188572 [main] gawk 4452 close: close(3)
  163  188735 [main] gawk 4452 fhandler_base::close: closing '???/datafile.txt' 
handle 0x12C

Thanks, Wolfgang

Re: mkshortcut (cygutils-1.4.14) free error

[Anthony Heading]

On Tue, Oct 27, 2015, at 01:29 AM, Mark Geisert wrote:
> I really appreciate the leads and code you've provided. Could we
> please discuss only on the Cygwin mailing list? That's the convention
> we have, barring extraordinary circumstances :) . It allows for
> public review.

I believe I did send everything to the mailing list. I may have copied
you directly also. Apologies if that was inconvenient.

> At that point I could reproduce your first mkshortcut issue. Your
> patch seems to fix that issue. So far, so good.

Great.

> The second issue with the non-absolute path is more problematic.
> Without your second patch, I do see the issue but only on the 2nd or
> later invocation. In other words, if the xyzzy.lnk file does not
> initially exist, the command 'src/mkshortcut/.libs/mkshortcut xyzzy'
> works and does create the link file. Another invocation then shows the
> error. Is it simply mis-reporting that there's an existing link file?

Yes. The hint in the error message is unhelpful I think, since a missing
directory is only one of a myriad of possible errors. As you note, an
existing link prompts the same message.

On the build I made on Windows 10, however, I hit the problem on the
very first invocation. I imagine you therefore are building on Windows 7
or earlier, which seems to produce binaries that work OK.  As I said, I
suspect this is because IPersistFile::Save has changed semantics, e.g.
per this link:

https://msdn.microsoft.com/en-us/library/windows/desktop/hh848036%28v=vs.85%29.aspx

I haven't verified this;  I don't know how why or whether gcc is
volunteering the executable to run in Windows 8 mode, or if there's a
manifest in some dll library stub, or whether the COM ID of the
IPersistFile interface is redirected by newer headers, or any similar
variant of Windows black magic,  but it seems to me like a good guess.

If you're going to stay building on Windows 7 then, I don't think this
latter patch is needed,  although it's hopefully harmless.  But I guess
without it the code will silently break when Windows 8 or newer comes
into the picture.

Regards

Anthony

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

Permissions on /var

[Jan Bruun Andersen]

Today, as I installed inetutils (I needed telnet for Cygwin; telnet
for Windows 10 does nothing; no error, no nothing) I got an error from
setup-084_64. The error message directed me to look at
/var/log/setup.log.full. Here is the relevant part, very near the end:

2015/10/28 00:55:10 running: C:\cygwin64\bin\dash.exe
"/etc/postinstall/0p_000_autorebase.dash"
cat: /var/lib/rebase/dynpath.d/*: No such file or directory
Updating package information in /var/cache/rebase/rebase_pkg.
from /etc/setup/inetutils-server.lst.gz...
from /etc/setup/inetutils.lst.gz...
Updating rebase information for installed dynamic objects in
/var/cache/rebase/rebase_lst.
Updating rebase information for installed executables in
/var/cache/rebase/rebase_exe.
removing /var/cache/rebase/rebase_dyn
creating empty /var/cache/rebase/rebase_dyn
Updating rebase information for user-defined dynamic objects
/var/cache/rebase/rebase_user.
Updating rebase information for user-defined executables
/var/cache/rebase/rebase_user_exe.
Rebasing with list /var/cache/rebase/rebase_all, built from
/var/cache/rebase/rebase_lst /var/cache/rebase/rebase_dyn
/var/cache/rebase/rebase_user.
2015/10/28 00:55:17 running: C:\cygwin64\bin\bash.exe --norc
--noprofile "/etc/postinstall/inetutils-server.sh"
*** Warning: The permissions on the directory /var are not correct.
*** Warning: They must match the regexp d..x..x..[xt]
*** ERROR: Problem with /var directory. Exiting.
*** Warning: The permissions on the directory /var are not correct.
*** Warning: They must match the regexp d..x..x..[xt]
*** ERROR: Problem with /var directory. Exiting.
2015/10/28 00:55:20 abnormal exit: exit code=1
2015/10/28 00:55:20 Changing gid to Administrators
Program directory for program link:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs
Desktop directory for desktop link: C:\Users\Public\Desktop
Desktop directory for desktop link: C:\Users\Public\Desktop
make_link C:\Users\Public\Desktop/Cygwin64 Terminal.lnk, Cygwin64
Terminal, C:\cygwin64\bin\mintty
make_link_2 (C:\cygwin64\bin\mintty, -i /Cygwin-Terminal.ico -,
C:\cygwin64\Cygwin-Terminal.ico, C:\Users\Public\Desktop/Cygwin64
Terminal.lnk)
2015/10/28 00:55:27 note: Installation Complete
2015/10/28 00:55:27 Ending cygwin install

I tracked the check down to a function in
/usr/share/csih/cygwin-service-installation-helper.sh. It checks the
permissions with a call to function csih_check_dir_perms which ends up
doing this:

2162   if /usr/bin/stat -c "%A" "$1" | /usr/bin/grep -Eq ^"$2"
2163   then
2164 true
2165   else
2166 csih_warning "The permissions on the directory $1 are not correct."
2167 csih_warning "They must match the regexp $2"
2168 return 1
2169   fi

Doing a manual check, /usr/bin/stat -c "%A" /var, confirms that the
permissions are indeed wrong:

$ /usr/bin/stat -c "%A" /var
drwx---r-x

Group-permissions are empty.

Now, as a coincidence, I have a month-old copy of a previous Cygwin
installation on an external disk. This is the permissions on the old
Cygwin:

$ ls -lg /g/cygwin64/
total 513
drwxr-xr-x+ 1 Unknown+Group0 Sep 25 15:22 bin
-rwxr-xr-x  1 Administratörer 59 Sep 12 00:03 Cygwin.bat
-rw-r--r--  1 Administratörer 157097 Sep 12 00:03 Cygwin.ico
-rw-r--r--  1 Administratörer  53342 Sep 12 00:03 Cygwin-Terminal.ico
drwxr-xr-x+ 1 Unknown+Group0 Sep 12 00:03 dev
drwxr-xr-x+ 1 Unknown+Group0 Sep 30 13:42 etc
drwxrwxrwt+ 1 Unknown+Group0 Sep 12 02:30 home
drwxr-xr-x+ 1 Unknown+Group0 Sep 25 15:22 lib
drwxr-xr-x+ 1 Unknown+Group0 Sep 12 00:02 sbin
drwxrwxrwt+ 1 Unknown+Group0 Sep 30 13:30 tmp
drwxr-xr-x+ 1 Unknown+Group0 Sep 18 20:19 usr
drwxr-xr-x+ 1 Unknown+Group0 Sep 12 00:02 var

And here is my current install:

$ ls -lg /c/cygwin64/
total 621
drwx---r-x+ 1 jabba0 Oct 28 00:55 bin
-rwxr-xr-x+ 1 jabba   71 Oct 26 00:48 Cygwin.bat
-rw-r--r--  1 Administratörer 157097 Oct 26 00:16 Cygwin.ico
-rw-r--r--  1 Administratörer  53342 Oct 26 00:16 Cygwin-Terminal.ico
drwx---r-x+ 1 jabba0 Oct 26 00:15 dev
drwx---r-x+ 1 jabba0 Oct 28 00:55 etc
drwx---rwt+ 1 jabba0 Oct 26 00:17 home
drwx---r-x+ 1 jabba0 Oct 27 18:37 lib
drwx---r-x+ 1 jabba0 Oct 26 00:26 sbin
drwx---rwt+ 1 jabba0 Oct 28 00:55 tmp
drwx---r-x+ 1 jabba0 Oct 27 17:33 usr
drwx---r-x+ 1 jabba0 Oct 27 18:37 var

As you can see, group-permissions is empty on a lot of the directories.

I don't know if it is relevant, but the old install is from a Windows
7 that was part of an AD-domain. The new install is my from my private
PC with Windows 10 Pro that (only) is part of a workgroup.

I guess I can just go ahead and give the group r-x permissions on /var
but I would be interested in knowing if this is a local problem, or a
common (real) problem.

Regards,
Jan

--
Problem reports:   http://cygwin.com/prob

gcc: cannot find -lubsan

[Steven Penny]

I have installed the "gcc-core" package:

$ gcc --version
gcc (GCC) 4.9.3

Using this file:

http://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/testsuite/c-c%2B%2B-common/ubsan/undefined-1.c;hb=382ecb

and this command:

gcc -fsanitize=undefined undefined-1.c

yields this result:

/usr/lib/gcc/x86_64-pc-cygwin/4.9.3/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lubsan
collect2: error: ld returned 1 exit status

--
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: Pop up GUI remotely via SSH

[Larry Hall (Cygwin)]

On 10/26/2015 12:07 PM, trimat wrote:

Hi all,
I would like to pup up on Windows 7 the GUI of a program started remotely
from SSH. I can't obtain this with *cygstart* even though I see the process
running in Windows Task Manager. Trying to add /--interactive/ flag to
Cygwin service /sshd/, the service doesn't start.

I am aware of the Windows restriction /Session 0 Isolation/ (introduced in
Windows Vista) but I read a few posts in which it seems possible. I have
tried lots of solutions but till now I am able to accomplish that not using
Cygwin but with *PsExec* (utility of /Windows Sysinternals/).

Any clue how to do it with Cygwin?


There have been a few spurious reports over the years of people getting
this to work post-XP with Cygwin's OpenSSH but never anything reliable and
reproducible.  So if there's a magic bullet, no one has been able to
classify it even if they can find it.  Or at least no one has reported it
here.  And while I would agree that PsExec seems to be able to make some
magic happen where ssh can't, it's also pretty clear that PsExec's magic is
compromising your system security, which is the exact opposite of OpenSSH's
intent.  Maybe it would be possible to take the best of both worlds but one
would at least need the code to PsExec to evaluate first before making a
definitive statement on whether this would even be possible.  Since the
source code to PsExec isn't available from the Sysinternals site, this 
avenue appears to be blocked.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

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

[ANNOUNCEMENT] Updated: exim-4.86-1

[Pierre A. Humblet]

I have updated Exim, the Mail Transfer Agent, to release 4.86, in 32 
and 64 bit versions.


This is a regular upstream update, see 
https://github.com/Exim/exim/wiki/ChangeLog


If you have questions or comments, please send them to the Cygwin
mailing list: cygwin at cygwin.com, mentioning "exim" in the subject line.

Pierre

---

To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

Exim is in the Mail category.

  *** 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 the above 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: mkshortcut (cygutils-1.4.14) free error

[Mark Geisert]

Anthony Heading writes:
> > The second issue with the non-absolute path is more problematic.
> > Without your second patch, I do see the issue but only on the 2nd or
> > later invocation. In other words, if the xyzzy.lnk file does not
> > initially exist, the command 'src/mkshortcut/.libs/mkshortcut xyzzy'
> > works and does create the link file. Another invocation then shows the
> > error. Is it simply mis-reporting that there's an existing link file?
> 
> Yes. The hint in the error message is unhelpful I think, since a missing
> directory is only one of a myriad of possible errors. As you note, an
> existing link prompts the same message.

Re the unhelpful hint, I was considering removing the guess it's making or
substituting something more generic.  I'm not sure it would help.  If
there were some way to get the underlying Windows error code we might be
able to map it to an errno but that seems like it might not be robust.  If
we only have OLE/COM error codes like the "E_FAIL" for an existing link
file, it seems hopeless.  I'll probably leave the error message text as-is
for now.
 
> On the build I made on Windows 10, however, I hit the problem on the
> very first invocation. I imagine you therefore are building on Windows 7
> or earlier, which seems to produce binaries that work OK.

Yes, I'm building on Windows 7, 64- and 32-bit as well as Windows XP.  No
plans at present to upgrade but I might need to consider VMs to test later
Windows versions.

> As I said, I
> suspect this is because IPersistFile::Save has changed semantics, e.g.
> per this link:
>
https://msdn.microsoft.com/en-us/library/
windows/desktop/hh848036%28v=vs.85%29.aspx
> 
> I haven't verified this;  I don't know how why or whether gcc is
> volunteering the executable to run in Windows 8 mode, or if there's a
> manifest in some dll library stub, or whether the COM ID of the
> IPersistFile interface is redirected by newer headers, or any similar
> variant of Windows black magic,  but it seems to me like a good guess.

I'll happily defer to your understanding of Those Black Arts :).
 
> If you're going to stay building on Windows 7 then, I don't think this
> latter patch is needed,  although it's hopefully harmless.  But I guess
> without it the code will silently break when Windows 8 or newer comes
> into the picture.

I think we should take advantage of the detective work you've done and
patch as you've suggested.  I'll add a comment to the effect that it's for
a specific Windows behavior change seen after Windows 7.  I'll add a link
to that MSDN page if our coding/doc conventions allow for that.

Thanks again for your patient and detailed help on this!

..mark




--
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: initial cygwin installation

[Warren Young]

On Oct 27, 2015, at 7:21 AM, Nellis, Kenneth wrote:
> 
> From: Warren Young
>> 
>> On Oct 25, 2015, at 3:11 PM, t s wrote:
>>> 
>>> Q: How do I install everything?
>>> A: You do not want to do this!
>> 
>> I explain this in more detail here:
>> 
>>  http://stackoverflow.com/a/21233990
> 
> For the hell of it I decided to check out this hidden feature.
> What I got was two dialog boxes popping up talking about
> Cygwin limitations, something about "this port of Avahi",
> references to Apple's "Bounjour mDNSResponder" service,
> and a link to http://support.apple.com/kb/DL999.
> 
> What's up with that?

That’s actually a great illustration of the point I tried to make.

You just asked setup.exe to install a whole bunch of software you do not 
actually need, so when it starts asking you questions about what you want done 
with this software, you are lost, because you don’t even know what the software 
*is*, much less how to use it.

So don’t do that. :)


--
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: initial cygwin installation

[Warren Young]

On Oct 28, 2015, at 12:05 AM, Warren Young  wrote:
> 
> You just asked setup.exe to install a whole bunch of software you do not 
> actually need, so when it starts asking you questions about what you want 
> done with this software, you are lost, because you don’t even know what the 
> software *is*, much less how to use it.
> 
> So don’t do that. :)

Oh, and not that it really matters, but the message box you got is because by 
installing everything, you included the avahi package, and setuo.exe is telling 
you that unless you do not also have a third-party Apple package installed 
(Bonjour) it isn’t going to do anything useful.

But you don’t actually *want* Avahi, so its error message is confusing and 
annoying, because you aren’t going to actually do anything about it.

This is why you don’t go telling Cygwin to install *everything*.  You don’t 
want everything.
--
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