Cygwin apps talking to Windows browsers?

Cygwin apps talking to Windows browsers?

[Jeffrey C Honig]

I use emacs under Cygwin (with Cygwin/XFree86 and/or Exceed) and would
like to switch to using mh-e in this environment.

One thing that I would like to do is to be able to click on a URL and
have my Windows browser (in this case Opera) be told to open the page.
Is there an app to allow this?

How about an app that would allow this from emacs running on another
host via X?

If there is no APP for this, is there an API for it?

Thanks.

Jeff

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Cygwin apps talking to Windows browsers?

[Igor Pechtchanski]

On Thu, 10 Jul 2003, Jeffrey C Honig wrote:

> I use emacs under Cygwin (with Cygwin/XFree86 and/or Exceed) and would
> like to switch to using mh-e in this environment.
>
> One thing that I would like to do is to be able to click on a URL and
> have my Windows browser (in this case Opera) be told to open the page.
> Is there an app to allow this?
>
> How about an app that would allow this from emacs running on another
> host via X?
>
> If there is no APP for this, is there an API for it?
>
> Thanks.
> Jeff

Take a look at cygstart.exe in the cygutils package.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Cygwin apps talking to Windows browsers?

[Jeffrey C Honig]

Cool!

I tried looking in the mail archives, but I guess I didn't use the right
search string...

Thanks.

Jeff

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP SP2

[Jeff.Hodges]

Thanks for looking at this Igor. Glad to know it isn't just me. 

pechtcha@cs.nyu.edu said:
>  And, lo and behold, on a plain WinXP SP1 (note, no SP2) I get the
> same behavior.

aha. innaresting. Well, I installed vanilla XP and then copied over a buncha 
directories from my old Win2k box, including \cygwin, and didn't play with it 
much before I upgraded to SP2. So I didn't really note anything while it was 
pre-SP2.

> Perhaps an update to Cygwin's symlink() implementation is in order? 

that's what I'm thinking.


corinna-cygwin@cygwin.com said:
> 2001.  The shortcuts have been added to Cygwin in 2001. 

ah, ok. I guess I didn't really start playing/using Cygwin in somewhat ernest 
until around then anyway.


corinna-cygwin@cygwin.com said:
> And it doesn't really fail.  The shortcut is still a shortcut in
> Windows Explorer.

Well, I claim that it *does* "really fail" because they (cygwin-created 
shortcut/symlinks) no longer -- on XP as compared to Win2k -- behave as they 
did. One uses file open/save dialogs very often when using windoze and on XP 
the cygwin-created shortcut/symlinks no longer behave as-documented (or 
as-in-an-explorer-window). So they don't "fail in all use cases", rather they 
"fail in some often-exercised use cases".


Seems to me we ought to see if we can't update the symlink() impl such that 
this is addressed. I'm betting there's some new attributes or whatever (as 
Igor notes) that've been added to symlinks in XP and if we can figure out what 
that is, and figure out what the minimum is we need to change in our 
cygwin-created .lnk files, we can perhaps (likely?) fix this without adversely 
affecting performance. Maybe there's some new system call on XP that we can 
use to create these buggers (if we're lucky)? After all, AFAIK, all cygwin 
cares about is the cygwin path being in the .lnk file's "comment" 
attribute/field, yes?

thanks again for looking into this,

JeffH



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP SP2

[Corinna Vinschen]

On Jan 15 08:17, Jeff.Hodges@KingsMountain.com wrote:
> Seems to me we ought to see if we can't update the symlink() impl such that 
> this is addressed. I'm betting there's some new attributes or whatever (as 
> Igor notes) that've been added to symlinks in XP and if we can figure out what 
> that is, and figure out what the minimum is we need to change in our 
> cygwin-created .lnk files, we can perhaps (likely?) fix this without adversely 
> affecting performance. Maybe there's some new system call on XP that we can 
> use to create these buggers (if we're lucky)? After all, AFAIK, all cygwin 
> cares about is the cygwin path being in the .lnk file's "comment" 
> attribute/field, yes?

I'm glad that you're talking about "us" as a group.  Anybody interested
in tracking that down?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP SP2

[Jeff.Hodges]

> I'm glad that you're talking about "us" as a group.  Anybody interested
> in tracking that down?

I'm not in a position to hack code on this unfortunately, but I can offer to 
test.

I suspect it's important in the longer term to track this down because they 
(MSFT) ~could~ make further changes down the road that break cygwin-created 
symlinks altogether (from the windoze perspective), which'd more than just 
"annoying".

JeffH



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP SP2

[Christopher Faylor]

On Mon, Jan 17, 2005 at 08:25:26AM -0800, Jeff.Hodges@KingsMountain.com wrote:
>> I'm glad that you're talking about "us" as a group.  Anybody interested
>> in tracking that down?
>
>I'm not in a position to hack code on this unfortunately, but I can offer to 
>test.
>
>I suspect it's important in the longer term to track this down because they 
>(MSFT) ~could~ make further changes down the road that break cygwin-created 
>symlinks altogether (from the windoze perspective), which'd more than just 
>"annoying".

No, Microsoft is not going to break things so that cygwin's symlinks no
longer operate.  Cygwin understands its own version of symlinks very well.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP SP2

[Sven Köhler]

>>I suspect it's important in the longer term to track this down because they 
>>(MSFT) ~could~ make further changes down the road that break cygwin-created 
>>symlinks altogether (from the windoze perspective), which'd more than just 
>>"annoying".
> 
> No, Microsoft is not going to break things so that cygwin's symlinks no
> longer operate.  Cygwin understands its own version of symlinks very well.

This comment is ridiculous. He clearly complained about MS-Software that 
cannot handle cygwin-created links, and you're talking about cygwin 
understand its own symlinks - well, think about it again.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP SP2

[Christopher Faylor]

On Mon, Jan 17, 2005 at 10:33:47PM +0100, Sven K?hler wrote:
>>>I suspect it's important in the longer term to track this down because 
>>>they (MSFT) ~could~ make further changes down the road that break 
>>>cygwin-created symlinks altogether (from the windoze perspective), 
>>>which'd more than just "annoying".
>>
>>No, Microsoft is not going to break things so that cygwin's symlinks no
>>longer operate.  Cygwin understands its own version of symlinks very well.
>
>This comment is ridiculous. He clearly complained about MS-Software that 
>cannot handle cygwin-created links, and you're talking about cygwin 
>understand its own symlinks - well, think about it again.

Apologies.  I took the word "altogether" to mean "completely" but
obviously missed the meaning implied by "from the windoze perspective".

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP

[Jeff.Hodges]

corinna-cygwin@cygwin.com said:
> There's a patch in current Cygwin CVS which should solve the icon
> problem.

Super. Tho, will fixing "the icon problem" also fix the behavior dichotomy 
between Explorer and Open/Save dialogs (which I noted in my original posting 
in this thread)?

>  If you want to use a shortcut in Cygwin and in native Windows, create
> it in Cygwin and don't touch it.

Indeed, and that appears to work fine on Win2k but not XP (yet).


JeffH



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP

[Jeff.Hodges]

> On Jan 31 12:25, Jeff.Hodges@KingsMountain.com wrote:
> > corinna-cygwin@cygwin.com said:
> > > There's a patch in current Cygwin CVS which should solve the icon
> > > problem.
> > 
> > Super. Tho, will fixing "the icon problem" also fix the behavior dichotomy 
> > between Explorer and Open/Save dialogs (which I noted in my original 
> > posting in this thread)?
> 
> Yes.

Great, thanks :)   

When might this find it's way into the setup.exe install?

thanks again,

JeffH



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP

[Christopher Faylor]

On Tue, Feb 01, 2005 at 11:43:04AM -0800, Jeff.Hodges@KingsMountain.com wrote:
>> On Jan 31 12:25, Jeff.Hodges@KingsMountain.com wrote:
>> > corinna-cygwin@cygwin.com said:
>> > > There's a patch in current Cygwin CVS which should solve the icon
>> > > problem.
>> > 
>> > Super. Tho, will fixing "the icon problem" also fix the behavior dichotomy 
>> > between Explorer and Open/Save dialogs (which I noted in my original 
>> > posting in this thread)?
>> 
>> Yes.
>
>Great, thanks :)   
>
>When might this find it's way into the setup.exe install?

Some time in the next year, for sure.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: hard link error on Vista with recent snapshots

[Herb Maeder]

On Jan 21 16:23, Corinna Vinschen wrote:
> On Jan 21 15:53, Corinna Vinschen wrote:
> > On Jan 19 07:30, Herb Maeder wrote:
> > > I'm seeing a error when creating hard links under Vista using the 
> > > cygwin1.dll snapshots starting at cygwin1-20070802.dll (through at 
> > > least cygwin1-20080112.dll). 
> > > 
> > > To reproduce:
> > >   * stop/exit all cygwin processes
> > >   * replace bin/cygwin1.dll with one of the snapshot dlls above
> > >   * fire up bash and run the following commands:
> > >       % rm -rf foo bar
> > >       % touch foo
> > >       % ln foo bar
> > >       ln: creating hard link `bar' => `foo': Permission denied
> > 
> > Thanks for the report.  I fixed this in CVS.  As it turned out, you
> > can't open a file with access flags set to 0.  ZwOpenFile requires at
>                                             ^^^^^
>                                             ...in Vista/Longhorn.
> 
> > least READ_CONTROL access.
>                          ^^^^
>                          ...in Vista/Longhorn.  0 works fine in earlier
> Windows versions.

Excellent!  Thank you very much for the explanation and the quick fix.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: invalid login gid in /etc/passwd does not show group name as 'mkgroup'

[Herb Maeder]

On 09 Oct 2008 13:05:36 +0200, Corinna Vinschen wrote:
> On Oct  7 11:22, Herb Maeder wrote:
> > The "Special values of user and group ids" section of the Cygwin User's 
> > Guide (http://cygwin.com/1.7/cygwin-ug-net.html#ntsec-ids) states:
> > 
> >    Also, since Cygwin release 1.3.20, if the current user is present in 
> >    /etc/passwd, but that user's login group is not present in /etc/group,
> >    the group name will be shown as 'mkgroup', again indicating the 
> >    appropriate command.
> > 
> > I don't see that this holds true, at least for the case of a Domain User.
> > In fact, I see that an invalid login group id will be shown as a group
> > name of 'Domain Users' even though there is no such gid listed in
> > /etc/group. This can be confusing since things appear to work normally on
> > the surface, but some commands may fail in some not-so-obvious ways as a
> > result of the invalid login gid.
> > 
> > . . .
> > 
> > I'm not sure if this is specific to Domain Users or not.  Also I don't
> > know if there is some valid reason for this behavior.
> 
> It's not specific to "Domain Users" and there's no *valid* reason for
> this.  The whole idea (which is a couple of years old, from 2002
> actually) is that Cygwin tries to have valid passwd and group entries in
> memory for *at least* the current user.  So, the situation from Cygwin's
> point of view develops along these lines:
> 
>   First, Cygwin checks the user token and finds the user's primary
>   group SID.
> 
>   Next it checks /etc/passwd and finds that the pgid is 898.
> 
>   There's no /etc/group entry for the primary gid of the current user?
>   Ok, let's create one so that this gid makes sense.
> 
>   Grab the SID.  Check if there's a group entry corresponding to that
>   SID.  Gotcha.  It's the entry with gid 10513 (which is ignored) and
>   the name "Domain Users".
> 
>   Ok, so let's add a group entry in memory like this:
> 
>     Domain Users:S-1-5-21-1936786716-3317986166-2952453263-513:898:
> 
>   Bingo.  We now have two entries for Domain Users, one with gid 898
>   and one with 10513.

Thanks for the explanation.  The behavior makes sense to me now.  

But I think that means that some of the information in the "Special values
of user and group ids" section of the Cygwin User's Guide is out of date.

Would it be appropriate to include some of the information from your
description above in that section?

> It's well meant since you now see the real name of your primary group.
> And, in theory, nothing bad should happen since the underlying SID is
> correct.  But the outcome is somewhat puzzeling, whatever Cygwin does.
> For instance, the gid of a file depends on the numbers.  If the pgid is
> smaller than the real gid, files are owned by the faked pgid and vice
> versa.  Either way, id will show you two group entries which have the
> same meaning, even if the names would differ (Domain User/mkgroup).

Also, it should be noted that some applications may behave unexpectedly
because of the situation ("rsync --link-dest", for one).  But I think your
solution below will give the user fair warning that something may not be
quite right.

On 09 Oct 2008 14:14:54 +0200, Corinna Vinschen wrote:
> I changed the code to create a fake group name which should explain
> what's going on.  Or maybe confuse the crap out of you.  But at least
> it's something we can use here on the list:                          
>                                            
>   $ ls -l foobar
> -rw-r--r-- 1 herb passwd/group_GID_clash(898/10513) 0 Oct 7 10:27 foobar

Cool!  It ain't pretty, but it will certainly give the user a fighting
chance to detect the issue before it causes obscure problems later on.
Plus since it will show up in "cygcheck -s" output, it will be useful for
folks on this list, as you say.

Would it be possible to add a case for this group name in the /etc/profile
"id -ng" case statement so that the user will be notified and have some
idea of what it means and what to do about it?

The "passwd/group_GID_clash" group name probably also deserves a mention
in the Cygwin User's Guide.

Thank you for investigating this issue and implementing a reasonable 
solution.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: invalid login gid in /etc/passwd does not show group name as 'mkgroup'

[Herb Maeder]

On 10 Oct 2008 11:35:08 +0200, Corinna Vinschen wrote:
> > But I think that means that some of the information in the "Special values
> > of user and group ids" section of the Cygwin User's Guide is out of date.
> > 
> > Would it be appropriate to include some of the information from your
> > description above in that section?
> 
> I don't think that these internals should be mentioned in the user's guide.

The point is moot since that section is due for a rewrite anyway.  I was
just trying to say that "some" of the information you provided was more
relevant (and certainly more correct) than what's there now.  In any
case, I'm sure that your sense of what level of detail is appropriate 
for the user is quite correct.

> > Would it be possible to add a case for this group name in the /etc/profile
> > "id -ng" case statement so that the user will be notified and have some
> > idea of what it means and what to do about it?
> 
> id is a generic tool from coreutils.  I for one wouldn't think it
> prudent to add special Cygwin code just to warn the user of some
> system specific corner case.

Perhaps my intention was not clearly stated.  I believe that a case
statement was added to /etc/profile long ago, specifically to warn users
that the group name was set to one of the cygwin special cases.  I'm 
referring to this statement in the cygwin default /etc/profile:

  # Check to see if mkpasswd/mkgroup needs to be run try and cut down the emails
  #   about this on the lists!
  # If this message keeps appearing and you are sure it's a mistake (ie, don't
  #   email about it!), comment out the test below.
  case `id -ng` in
  mkpasswd )
    echo "Your group is currently \"mkpasswd\".  This indicates that"
    echo "the /etc/passwd (and possibly /etc/group) files should be rebuilt."
    echo "See the man pages for mkpasswd and mkgroup then, for example, run"
    echo "mkpasswd -l [-d] > /etc/passwd"
    echo "mkgroup  -l [-d] > /etc/group"
    echo "Note that the -d switch is necessary for domain users."
    ;;

  . . .

If that case statement is no longer prudent, perhaps it should be removed.

But if it ends up sticking around, then it probably makes sense to account
for the additional special case that was just introduced:

  passwd/group_GID_clash* )
    echo "Your group is currently \"passwd/group_GID_clash\".  This indicates"
    echo "blah, blah, blah..."
    ;;

> > The "passwd/group_GID_clash" group name probably also deserves a mention
> > in the Cygwin User's Guide.
> 
> That's right, but this part of the ntsec documentation is waiting
> patiently for an update for a long time anyway.  I just had always
> more important stuff to do (looking tv, sleeping, ...)

I can certainly appreciate that!  I knew that the 1.7 version of the
user's guide had undergone revision, but I didn't realize that this
section was still on the todo list.  I'm sure it will all sort itself 
out nicely in the update.

Thanks again,
Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: invalid login gid in /etc/passwd does not show group name as 'mkgroup'

[Herb Maeder]

On 13 Oct 2008 17:54:36 +0200, Corinna Vinschen wrote:
> > But if it ends up sticking around, then it probably makes sense to account
> > for the additional special case that was just introduced:
> > 
> >   passwd/group_GID_clash* )
> >     echo "Your group is currently \"passwd/group_GID_clash\".  This indicat
es"
> >     echo "blah, blah, blah..."
> >     ;;
> > 
> > > > The "passwd/group_GID_clash" group name probably also deserves a mentio
n
> > > > in the Cygwin User's Guide.
> 
> Yes, you're right, adding a case for passwd/group_GID_clash would be
> nice.  http://cygwin.com/acronyms/#SHTDI  I'm sure the maintainer
> of the base-passwd package would appreciate a patch.

Sure, I'd be happy to do that.

But before submitting a patch, I'd like to make sure I know what I'm talking
about so I can submit a proper patch for the whole case statement.  Can you
confirm that the following are correct?

  1) It is no longer possible to end up with the "mkgroup_l_d" group name.
     If I understand it correctly, this possibility went away in version
     1.30 of mkgroup.c.  If so, that case should be removed from the 
     /etc/profile case statement.

  2) The group name will be 'mkpasswd' if the current user's effective gid 
     is not in /etc/group and the effective uid is not in /etc/passwd.

  3) The group name will be 'passwd/group_GID_clash(%ld/%ld)' if the 
     current user's effective gid is not in /etc/group, the effective
     uid is in /etc/passwd, and the gid associated with the user's SID is
     in /etc/group.

  4) The group name will be 'mkgroup' if the current user's effective gid 
     is not in /etc/group, the effective uid is in /etc/passwd, and the
     gid associated with the user's SID is not in /etc/group.	


If that's all correct, perhaps this chunk of pseudo-code says it more 
succinctly:

    if (current users effective gid not in /etc/group) {
      if (current users effective uid not in /etc/passwd) {
        group_name="mkpasswd";
      } else if (current users SID group is in /etc/group) {
        group_name="passwd/group_GID_clash(egid/pgsid)"
      } else {
        group_name="mkgroup";
      } 
    }


I'd like to include some version of that information in the comment above
the case statement.  My thinking is that if someone found where the
message is being generated, they are probably looking for more information
than "try running mkpasswd and mkgroup", so stating the meaning of the
special group names is probably warranted.

I'd also like to provide a bit more information in the statements that are
printed out to the user.  Perhaps something like this (where the second 
echo statement is new):

  case `id -ng` in
  mkpasswd )
    echo "Your group is currently \"mkpasswd\".  This indicates that"
    echo "your gid is not in /etc/group and your uid is not in /etc/passwd."
    echo "The /etc/passwd (and possibly /etc/group) files should be rebuilt."
    echo "See the man pages for mkpasswd and mkgroup then, for example, run"
    echo "mkpasswd -l [-d] > /etc/passwd"
    echo "mkgroup  -l [-d] > /etc/group"
    echo "Note that the -d switch is necessary for domain users."
    ;;

To summarize, I'm proposing to:

   * add the 'passwd/group_GID_clash' case
   * delete the 'mkgroup_l_d' case
   * provide definitions for the special group names in the comment above
     the case statement
   * modify the statements to the user to more accurately describe the 
     nature of the problem

Any opinions on if these modifications are a good idea or not?  

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bash crashes on Win Serv 2008

[Freddy Jensen]

   >From: Corinna Vinschen <corinna-cygwin@cygwin.com>
   >Date: Thu Oct 23 2008 11:53am
   >To:   "cygwin@cygwin.com" <cygwin@cygwin.com>
   >Subj: Re: cygwin bash crashes on Win Serv 2008
   >
   >On Oct 23 17:52, Dave Korn wrote:
   >> Corinna Vinschen wrote on 23 October 2008 17:21:
   >> >     Attempt to execute non-executable address 00419d97
   >> >
   >> > Huh?  Why should this address (this application function) be
   >> > "non-executable", while it's executable when TS is not installed?
   >>
   >>   DEP?  ASLR?  SafeSEH?  As well as "dg" there are some other commands in
   >> windbg that'll show you memory types and attributes.
   >
   >Huh!  It was DEP.  Apparently when installing TS, the default setting
   >for DEP is switched from "Turn on DEP for essential Windows programs
   >and services only" to "Turn on DEP for all programs and services
   >[with execptions]".  I switched it back, rebooted, and now bash, grep
   >and GDB work fine.
   >

Thanks everyone. Finding the root cause and
the workaround is a lifesaver for us.

Appreciate it.

Freddy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [Fwd: Apologies for multiple messages (Please Help!)]

[Herb Maeder]

On 24 Oct 2008 10:30:08 +0200, Corinna Vinschen wrote:
> we have a strange mail duplication here on the cygwin ML.  The
> mail with Message ID <0ML4cO-1Kt7yy1h2s-000U3k@mx.kundenserver.de>
> is duplicated over and over again.  Could something on sourceware
> be the culprit?

Now that is interesting!  I see the message come back to me with no
Message-ID in the headers (sample included below, with '@' and '.'
replaced to protect the innocent).

I have a theory as to what's going on...

I believe that adding the Message-ID field is the responsibility of the
MUA.  But some mail servers add a Message-ID if it is missing.  I just
verified that my MUA was not creating the Message-ID field, and I'm
guessing that one got added somewhere along the way to Corinna's mailbox.

I don't think that the missing Message-ID is the root cause of the mail
duplication problem.  But I do believe that the missing Message-ID causes
the workaround to the problem to fail.  I'm guessing that the
sourceware.org server may detect and prevent duplicated messages based on 
the Message-ID field.  But since there wasn't one in my message, that
mechanism did not work.

(I've got a hunch that the root cause may be some miscommunication between
the servers due to timeouts or something, but I have no way to verify
that).

In any case, if my guess about the misssing Message-ID is correct, then
I believe that a few of things should be done:

  1) I should make sure that my MUA generates the Message-ID field on
     outgoing messages.  I believe that I have fixed this now (and this
     message should have a "@maeder.org" Message-ID).

  2) If the cygwin mail server is truly depending on Message-ID to stop
     this message duplication, it should somehow ensure that it is always
     there.  One option would be to prevent posts to the list that are 
     missing the Message-ID field (with some reasonable return error
     message to the sender).  NOTE: I'm not sure if generating a Message-ID 
     field on the cygwin mail server would work (that might just add 
     a unique Message-ID on each duplicated message, I'm not sure).

  3) Determine and fix the root of the duplication problem (though I'm not 
     sure how feasible this would really be).


I think most modern MUA's add the Message-ID field, but it is not a strict
requirement.  Implementing something for 2) above may help avoid the
duplication problem for mail sent from misconfigured and/or old school mail
clients (nmh in my case).

How to stop the still repeating evil message?  I still haven't a clue...

Herb.



From cygwin-return-145237-maeder-cygml=maeder DOT org AT cygwin DOT com Thu Oct 23 20:44:41 2008
Return-Path: <cygwin-return-145237-maeder-cygml=maeder DOT org AT cygwin DOT com>
Delivered-To: maeder-cygml AT maeder DOT org
Received: (qmail 87667 invoked by uid 18834); 23 Oct 2008 20:44:41 -0000
Received: from unknown (HELO sourceware DOT org) ([209.132.176.174])
          (envelope-sender <cygwin-return-145237-maeder-cygml=maeder DOT org AT cygwin DOT com>)
          by 192.220.73.146 (qmail-ldap-1.03) with SMTP
          for <maeder-cygml AT maeder DOT org>; 23 Oct 2008 20:44:41 -0000
Received: (qmail 31157 invoked by alias); 23 Oct 2008 20:44:40 -0000
Received: (qmail 31140 invoked by uid 22791); 23 Oct 2008 20:44:38 -0000
X-Spam-Check-By: sourceware DOT org
Received: from maeder DOT org (HELO maeder DOT org) (192.220.73.146)     by sourceware DOT org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 20:43:33 +0000
Received: (qmail 86029 invoked by uid 18834); 23 Oct 2008 20:43:31 -0000
Received: from unknown (HELO maeder DOT org) ([127.0.0.1])           (envelope-sender <maeder-cygml AT maeder DOT org>)           by 127.0.0.1 (qmail-ldap-1.03) with SMTP           for <cygwin AT cygwin DOT com>; 23 Oct 2008 20:43:31 -0000
To: cygwin AT cygwin DOT com
From: Herb Maeder <maeder-cygml AT maeder DOT org>
In-reply-to: "Manning, Sid" <sidneym AT qualcomm DOT com> 's message of                  Mon, 20 Oct 2008 11:53:19 PDT.
Subject: Re: Compile time Local Cygwin vs. VMware session on same system
Date: Thu, 23 Oct 2008 13:43:30 -0700
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin DOT com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-maeder-cygml=maeder DOT org AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware DOT org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware DOT org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Status: RO
X-Status: 
X-Keywords:                 
X-UID: 4142

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: [Fwd: Apologies for multiple messages (Please Help!)]

[Dave Korn]

Herb Maeder wrote on 24 October 2008 18:05:

> I have a theory as to what's going on...
> 
> I believe that adding the Message-ID field is the responsibility of the
> MUA.  

  Yep.

> But some mail servers add a Message-ID if it is missing.

  Yep.  In my case, it gets added at my local server when I receive the post
from sourceware.org.

> I don't think that the missing Message-ID is the root cause of the mail
> duplication problem.  But I do believe that the missing Message-ID causes
> the workaround to the problem to fail.

  Yep and yep.

>  I'm guessing that the
> sourceware.org server may detect and prevent duplicated messages based on
> the Message-ID field.

  Yep, this is a standard dup-filtering strategy for MTAs.

>  But since there wasn't one in my message, that
> mechanism did not work.

  Indeed it could not.

> (I've got a hunch that the root cause may be some miscommunication between
> the servers due to timeouts or something, but I have no way to verify
> that).

  You don't have access to the maeder.org server?

> In any case, if my guess about the misssing Message-ID is correct, then
> I believe that a few of things should be done:
> 
>   1) I should make sure that my MUA generates the Message-ID field on
>      outgoing messages.  I believe that I have fixed this now (and this
>      message should have a "@maeder.org" Message-ID).

  Confirmed.

>   2) If the cygwin mail server is truly depending on Message-ID to stop
>      this message duplication, it should somehow ensure that it is always
>      there.  One option would be to prevent posts to the list that are
>      missing the Message-ID field (with some reasonable return error
>      message to the sender).  NOTE: I'm not sure if generating a
>      Message-ID field on the cygwin mail server would work (that might
>      just add a unique Message-ID on each duplicated message, I'm not
> sure). 

  Well, it might be possible to make a msgid based on a hash of the body of
the email.  But that would have the consequence of making it easier to impose
a computational-load DoS on the machine by sending it lots of spam with no
msgid headers.  Probably an outright rejection would be best.

>   3) Determine and fix the root of the duplication problem (though I'm not
>      sure how feasible this would really be).

> How to stop the still repeating evil message?  I still haven't a clue...

  Those headers you showed us are completely conclusive:

> >From message 1:
>   Received: from maeder.org (HELO maeder.org) (192.220.73.146)     by
sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 20:43:33 +0000
>   Received: (qmail 86029 invoked by uid 18834); 23 Oct 2008 20:43:31 -0000
> 
> >From message 2:
>   Received: from maeder.org (HELO maeder.org) (192.220.73.146)     by
sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 20:50:13 +0000
>   Received: (qmail 86029 invoked by uid 18834); 23 Oct 2008 20:43:31 -0000
> 
> >From message 3:
>   Received: from maeder.org (HELO maeder.org) (192.220.73.146)     by
sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 21:10:13 +0000
>   Received: (qmail 86029 invoked by uid 18834); 23 Oct 2008 20:43:31 -0000


  What this shows is that maeder.org (192.220.73.146) is repeatedly contacting
sourceware.org to deliver the mail.  You sent the mail once only - the
repeated (qmail invoked by uid) lines all have the same stamp; your local MTA
accepted and spooled it, and is trying to send it to sourceware.org.  Because
it has no msgid, sourceware.org thinks it's a new message every time.  The
problem is caused by the fact that sourceware.org accepts the post, but
maeder.org thinks it hasn't, and retries a while later (looks like a slowly
increasing backoff is involved).

  You need to look at the mail logs on maeder.org and see what it thinks has
happened during the conversation at sourceware.org.  It may be that
sourceware.org is bogusly both accepting the mail and yet indicating an error
code to maeder.org, or it may be that maeder.org is misinterpreting the status
code from sourceware.org and only thinking it means "not accepted" when it in
fact means something like "accepted with warnings".

  I don't have access to the sourceware logs, but you may be able to read
/var/log/maillog on maeder.org even if you only have standard user-level
access, it's quite common not to need root access just to read the logs.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7)

[Herb Maeder]

On 07 Nov 2008 12:00:56 +0100, Corinna Vinschen wrote:
> I've just updated the version of OpenSSH to 5.1p1-6.
> 
> This is a bugfix release which fixes a bug in the ssh-host-config script
> which stumbles over user names with a substring of "ssh" in them and
> thinks that ssh processes are still running.
> 
> There's an equivalent new 5.1p1-7 release for Cygwin 1.7 testers.

It seems that setup-2.ini on the mirrors is actually pointing to 5.1p1-6, 
which does not exist in release-2.  

It looks like the modification time of the tarball is 3 minutes after
setup-2.ini, so perhaps setup-2.ini just needs to be regenerated.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7)

[Christopher Faylor]

On Fri, Nov 07, 2008 at 09:51:24AM -0800, Herb Maeder wrote:
>On 07 Nov 2008 12:00:56 +0100, Corinna Vinschen wrote:
>> I've just updated the version of OpenSSH to 5.1p1-6.
>> 
>> This is a bugfix release which fixes a bug in the ssh-host-config script
>> which stumbles over user names with a substring of "ssh" in them and
>> thinks that ssh processes are still running.
>> 
>> There's an equivalent new 5.1p1-7 release for Cygwin 1.7 testers.
>
>It seems that setup-2.ini on the mirrors is actually pointing to 5.1p1-6, 
>which does not exist in release-2.  
>
>It looks like the modification time of the tarball is 3 minutes after
>setup-2.ini, so perhaps setup-2.ini just needs to be regenerated.

There have been some problems regenerating setup-2.ini today.  I'm waiting
for some package maintainers to fill me in on what's going on with their
packages so that we can fix the problem.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7)

[Herb Maeder]

On 07 Nov 2008 12:00:56 +0100, Corinna Vinschen wrote:   
> This is a bugfix release which fixes a bug in the ssh-host-config script
> which stumbles over user names with a substring of "ssh" in them and    
> thinks that ssh processes are still running.                        
>                                             
> There's an equivalent new 5.1p1-7 release for Cygwin 1.7 testers.
                           
It looks like there may be a problem with the ssh-host-config in the
5.1p1-7 release.  It now uses "mount -t", but the -t option is no longer
valid in the 1.7 version of mount.

  % ssh-host-config
  *** Info: Creating default /etc/ssh_config file
  *** Info: Creating default /etc/sshd_config file
  *** Info: Privilege separation is set to yes by default since OpenSSH 3.3.
  *** Info: However, this requires a non-privileged account called 'sshd'.
  *** Info: For more info on privilege separation read /usr/share/doc/openssh/README.privsep.
  *** Query: Should privilege separation be used? (yes/no) yes
  *** Info: Updating /etc/sshd_config file
  mount: unknown option -- t
  Usage: mount [OPTION] [<win32path> <posixpath>]
  Display information about mounted filesystems, or mount a filesystem
  
    -c, --change-cygdrive-prefix change the cygdrive path prefix to <posixpath>
    -f, --force force mount, don't warn about missing mount
                                  point directories
    -h, --help                    output usage information and exit
    -m, --mount-entries write fstab entries to replicate mount points
                                  and cygdrive prefixes
    -o, --options X[,X...]        specify mount options
    -p, --show-cygdrive-prefix show user and/or system cygdrive path prefix
    -v, --version                 output version information and exit
  
  Valid options are:

    binary,text,exec,notexec,cygexec,nosuid,acl,noacl,posix=1,posix=0

  grep: /ssh-host-config.2052/services: No such file or directory
  grep: /ssh-host-config.2052/services: No such file or directory
  /usr/bin/ssh-host-config: line 105: /ssh-host-config.2052/services: No such file  or directory
  *** Warning: Adding ssh to C:umount: /ssh-host-config.2052: Invalid argument


  *** Warning: The following functions require administrator privileges!

  *** Query: Do you want to install sshd as a service?


This is on a vista machine with a clean 1.7 install (with openssh-5.1p1-7
installed from a local mirror since the public mirrors are broken right now).

Switching it back to "mount -o text" seems to work (I'm not sure if that
should be made conditional on 1.7 though).

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7)

[Herb Maeder]

On 07 Nov 2008 12:00:56 +0100, Corinna Vinschen wrote:   
> This is a bugfix release which fixes a bug in the ssh-host-config script
> which stumbles over user names with a substring of "ssh" in them and
> thinks that ssh processes are still running.

Is the intent now to catch only processes named 'sshd'?  If so, the
current "grep -q 'sshd*$'" may still be a little too loose.  For example, 
it could match stuff like "/home/user/flosshdd".  Ok, maybe not likely, 
but still it would cause the script to end in an error.

Assuming we can depend on "ps -ef" always printing full path names without 
any arguments, then "grep -q '/sshd$'" might do the trick.  Is there any
reason to catch multiple trailing d's?

If a more loose matching scheme is really desired, it might be helpful to 
print out the matching ps lines before generating the error (just so
that it's more obvious to the user as to what is going on).

Sorry if this is too nit-picky.  I just happened to notice it when I was
looking at other stuff.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] Updated: OpenSSH-5.1p1-6 (-7)

[Christopher Faylor]

On Fri, Nov 07, 2008 at 01:37:44PM -0800, Herb Maeder wrote:
>On 07 Nov 2008 12:00:56 +0100, Corinna Vinschen wrote:   
>> This is a bugfix release which fixes a bug in the ssh-host-config script
>> which stumbles over user names with a substring of "ssh" in them and
>> thinks that ssh processes are still running.
>
>Is the intent now to catch only processes named 'sshd'?  If so, the
>current "grep -q 'sshd*$'" may still be a little too loose.  For example, 
>it could match stuff like "/home/user/flosshdd".  Ok, maybe not likely, 
>but still it would cause the script to end in an error.
>
>Assuming we can depend on "ps -ef" always printing full path names without 
>any arguments, then "grep -q '/sshd$'" might do the trick.  Is there any
>reason to catch multiple trailing d's?

It's possible that Corinna was looking for zero or more d's.

So, something like grep -qP '/sshd?' would accommodate that.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 10 Nov 2008 15:48:15 +0100, Corinna Vinschen wrote:
> On Nov  8 07:44, Herb Maeder wrote:
> > Running sshd (openssh 5.1p1-d57 or 5.1p1-7) on cygwin-1.7 and vista
> > results in the following error:
> > 
> >         % ssh localhost pwd
> >         herb@localhost's password:
> >         initgroups: Permission denied
> > 
> > I think this should be easily reproducible with a fresh installation of
> > just cygwin 1.7 base + openssh running on a generic vista confiuration
> > with UAC enabled.  
> > 
> > Can anyone confirm this?  If it is specific to my setup, I'll dig deeper
> > and provide more information.
> 
> I can't reproduce this.  A permission denied in initgroups point to
> insufficient privileges of the account running sshd.  Are you running
> sshd with a local cyg_server account but trying to login with a domain
> account?  Maybe there's a permission problem.

You are correct.  I was indeed running sshd with a local cyg_server, but
logging in with a domain account.  I tried firing up sshd as me, and I was 
able to log in successfully.  Thanks for pointing me in the right
direction.

I think this means that "ssh-host-config -y" followed by "cygrunsrv
--start sshd" no longer works for setting up sshd for domain users 
on vista (though it still does on XP).  What should be the recommended 
procedure for setting up sshd on Vista + cygwin-1.7?  

Am I correct in assuming that you would need to have access to an account 
with Domain Administrator privileges in order to allow multiple domain 
users to ssh into a 1.7 vista machine?

And if you don't have access to such an account, the best you can do is
fire up sshd as yourself (or perhaps one sshd per user on different ports)?  
I'm guessing that will allow you and local users to ssh in (assuming your
domain account has local administrator access).

Looking ahead, I suspect that this combo (sshd + 1.7 + vista + domain user) 
will be pretty common.  Is there a plan for steering users in the right
direction during the setup of sshd, or maybe giving a more descriptive 
error message?

> 1. Yes, ssh-host-config has to be run elevated, as with all applications
>    requiring actual admin privileges.  There's no way to elevate a child
>    process running in the same console window.  Microsoft tweaked the
>    ShellExecute() call in shell32.dll heavily to allow the UAC stuff,
>    but neglected to allow applications using the CreateProcess() call to
>    do the same.  ShellExecute is not an option to use in Cygwin processes.

Bum deal.  But thanks for the explanation.  That clarifies what I was
seeing.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Corinna Vinschen]

On Nov 12 16:57, Herb Maeder wrote:
> On 10 Nov 2008 15:48:15 +0100, Corinna Vinschen wrote:
> [...]
> Am I correct in assuming that you would need to have access to an account 
> with Domain Administrator privileges in order to allow multiple domain 
> users to ssh into a 1.7 vista machine?

I'm not quite sure about this.  I don't claim to understand all the does
and dont's of Windows domains either.

However, I have a working result by creating a domain account with the
required permissions called cyg_server, then create a cyg_server entry
in passwd using mkpasswd, then start ssh-host-coonfig.

> And if you don't have access to such an account, the best you can do is
> fire up sshd as yourself (or perhaps one sshd per user on different ports)?  
> I'm guessing that will allow you and local users to ssh in (assuming your
> domain account has local administrator access).
> 
> Looking ahead, I suspect that this combo (sshd + 1.7 + vista + domain user) 
> will be pretty common.  Is there a plan for steering users in the right
> direction during the setup of sshd, or maybe giving a more descriptive 
> error message?

The ssh-host-config script only covers the simpler approaches for home
users.  Right now, a professional administrator for a Windows domain
will have to know a bit, or ask here.

Ideally, somebody would take a heart and

- Add more code to ssh-host-config to allow more smooth operations
  in a domain environment.
- Add to the documentation to explain the problems.

But right now that won't be me.

> > 1. Yes, ssh-host-config has to be run elevated, as with all applications
> >    requiring actual admin privileges.  There's no way to elevate a child
> >    process running in the same console window.  Microsoft tweaked the
> >    ShellExecute() call in shell32.dll heavily to allow the UAC stuff,
> >    but neglected to allow applications using the CreateProcess() call to
> >    do the same.  ShellExecute is not an option to use in Cygwin processes.
> 
> Bum deal.  But thanks for the explanation.  That clarifies what I was
> seeing.

Actually there is a way to elevate a console application which is the
manifest file.  Unfortunately this only works for executables, not for
scripts.

I didn't try it myself, but maybe something like this works:

  $ cd /bin
  $ cp bash.exe bash-elevated.exe
  $ sed 's/nstall\.exe/bash-elevated.exe/g' < install.exe > bash-elevated.exe.manifest
  $ sed '1s/bash/bash-elevated/' < ssh-host-config > ssh-host-config-elevated
  $ ssh-host-config-elevated

Sometimes adding a manifest file to an executable doesn't work immediately
due to some cashing in Windows but basically this should work.


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Corinna Vinschen]

On Nov 13 11:35, Corinna Vinschen wrote:
> On Nov 12 16:57, Herb Maeder wrote:
> > Bum deal.  But thanks for the explanation.  That clarifies what I was
> > seeing.
> 
> Actually there is a way to elevate a console application which is the
> manifest file.  Unfortunately this only works for executables, not for
> scripts.
> 
> I didn't try it myself, but maybe something like this works:
> 
>   $ cd /bin
>   $ cp bash.exe bash-elevated.exe
>   $ sed 's/nstall\.exe/bash-elevated.exe/g' < install.exe > bash-elevated.exe.manifest
>   $ sed '1s/bash/bash-elevated/' < ssh-host-config > ssh-host-config-elevated
>   $ ssh-host-config-elevated
> 
> Sometimes adding a manifest file to an executable doesn't work immediately
> due to some cashing in Windows but basically this should work.

On second thought, this can't work.  The manifest file starts the
application with an execution level of "asInvoker" which means *not*
elevated.  Even if you change this to elevated (I don't know the right
level string for this off hand), the problem that you won't get an
elevation prompt when a process gets started through CreateProcess
remains the same.  Too bad.  The mainfests work in one direction, but
they don't in the other.  Baeh.


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 13 Nov 2008 14:57:20 +0100, Corinna Vinschen wrote:
> On Nov 13 11:35, Corinna Vinschen wrote:
> > On Nov 12 16:57, Herb Maeder wrote:
> > > Bum deal.  But thanks for the explanation.  That clarifies what I was
> > > seeing.
> > 
> > Actually there is a way to elevate a console application which is the
> > manifest file.  Unfortunately this only works for executables, not for
> > scripts.
> > 
> > I didn't try it myself, but maybe something like this works:
> > 
> >   $ cd /bin
> >   $ cp bash.exe bash-elevated.exe
> >   $ sed 's/nstall\.exe/bash-elevated.exe/g' < install.exe > bash-elevated.e
xe.manifest
> >   $ sed '1s/bash/bash-elevated/' < ssh-host-config > ssh-host-config-elevat
ed
> >   $ ssh-host-config-elevated
> > 
> > Sometimes adding a manifest file to an executable doesn't work immediately
> > due to some cashing in Windows but basically this should work.
> 
> On second thought, this can't work.  The manifest file starts the
> application with an execution level of "asInvoker" which means *not*
> elevated.  Even if you change this to elevated (I don't know the right
> level string for this off hand), the problem that you won't get an
> elevation prompt when a process gets started through CreateProcess
> remains the same.  Too bad.  The mainfests work in one direction, but
> they don't in the other.  Baeh.

Yeah, I think that corresponds to what I found... there's no way to
elevate a command without somehow firing off another application like a
separate cmd window.

Along similar lines, I tried to "cp /bin/bash.exe /bin/bash-elev.exe",
then set bash-elev to run as adminstrator, with Right Click -> Properties ->
Compatibility then check the "Run this program as an administrator" box.
There was no love when invoking bash-elev.exe directly from a bash command
line, but invoking it via a cmd shell did the trick.

The best I was able to do was to create an "elev.sh" script like this:

    #!/bin/bash
    eval 'cmd /c bash-elev -c '\'${1+"$@"}\'''

I know that the quoting is not quite right to deal with all possible
arguments correctly, but it should be good enough to fire off some generic
elevated commands.

For example:

    elev.sh /bin/ssh-host-config -y

or even something like this will work:

    elev.sh "/bin/bash somescript.sh \"a b\" c > out; sleep 4"

If elev.sh is called from an already elevated bash shell (run with "Run as
administrator"), then there will be no UAC prompt and the output will
appear normally in the shell.  But if the invoking shell is not elevated,
then it will display the UAC prompt, and fire off a separate cmd shell
window.  The bummer is that for normal commands, any output will be
displayed in the new cmd window, which will exit immediately (i.e. user
won't see the output).  Though it is possible to redirect the output to
a file.

Still, even with these drawbacks, something like this might be useful for
us in ssh-host-config.  If the invoking shell is already elevated, things
will pretty much work the way they do now.  But if it is invoked from a
normal shell, the user would get prompted to elevate, and then the
ssh-host-config queries and input would happen in a different cmd window.
Not great, but still better than just exiting with an error (or, worse, 
trying to continue with insufficient privileges).

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Corinna Vinschen]

On Nov 13 15:48, Herb Maeder wrote:
> Still, even with these drawbacks, something like this might be useful for
> us in ssh-host-config.  If the invoking shell is already elevated, things
> will pretty much work the way they do now.  But if it is invoked from a
> normal shell, the user would get prompted to elevate, and then the
> ssh-host-config queries and input would happen in a different cmd window.
> Not great, but still better than just exiting with an error (or, worse, 
> trying to continue with insufficient privileges).

Actually this isn't a ssh-host-config problem, but a generic problem
for all admin tasks.  Installing any service requires elevation, or
running in a Admin shell.  I'm not really convinced that we need it.
Admins running admin tasks should know that they need admin privileges.
What you're asking for is a convenience, not a necessity.

Having said that, if we want that I think the Vista elevation stuff
should go into csih, rather than ssh-host-config script, so all admin
scripts can use the functionality easily in the long run.

And I'm sure Charles wouldn't mind to get csih patches ;)


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 13 Nov 2008 11:35:43 +0100, Corinna Vinschen wrote:
> > Looking ahead, I suspect that this combo (sshd + 1.7 + vista + domain user)
> > will be pretty common.  Is there a plan for steering users in the right
> > direction during the setup of sshd, or maybe giving a more descriptive 
> > error message?
> 
> The ssh-host-config script only covers the simpler approaches for home
> users.  Right now, a professional administrator for a Windows domain
> will have to know a bit, or ask here.
> 
> Ideally, somebody would take a heart and
> 
> - Add more code to ssh-host-config to allow more smooth operations
>   in a domain environment.
> - Add to the documentation to explain the problems.
> 
> But right now that won't be me.

Understood.  Thanks for providing the game plan in any case.

As for me, I've unfortunately just lost all access to my domain account
and vista test machines.  So, although I would like help, I don't think
that I'll be able to accomplish much on this front in the short term.  But
I'll see what I can do to get the ball rolling in the right direction.

Is this the appropriate document to update with an explanation of the
problems?

   /usr/share/doc/Cygwin/openssh.README

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 14 Nov 2008 10:53:12 +0100, Corinna Vinschen wrote:
> Actually this isn't a ssh-host-config problem, but a generic problem
> for all admin tasks.  Installing any service requires elevation, or
> running in a Admin shell.  I'm not really convinced that we need it.
> Admins running admin tasks should know that they need admin privileges.
> What you're asking for is a convenience, not a necessity.

Yes, I agree that we are talking about a generic problem for tasks
requiring elevation.  And perhaps I took it a step too far suggesting that
we might want to provide a mechanism to elevate automatically (a lame
attempt at being compatible with pre-vista OSes).  So I take that back.

I'd really just like to understand what the recommended behavior should be
for admin tasks that are invoked from underprivileged shells under vista
with UAC turned on.  In other words, should we do anything to ease a
cygwin user's transition to Vista?

Right now, the documentation doesn't address any migration to vista
issues.  So we are pretty much ensuring that new vista users will stumble
onto the cygwin elevation problems the hard way.  And this list or its
archives are the only resources to figure out what to do.  We can do
better than that.

Bottom line, any design decision that reduces noise on this list will have
the added benefit of providing a better experience to the user (win-win).
Or put differently, an inconvience to the user can translate to an
inconvenience to the list.

For example, would these be reasonable goals for admin tasks requiring
elevation?

   * Provide documentation and recommendations for vista specific issues
     (UAC recommendations, how to elevate, commands requiring
     elevation,...).  Is the user guide the right place for that?

   * When a command requires elevation, detect if the process is already
     elevated. If not, exit with an error and a reasonable error statement
     indicating the nature of the problem (and perhaps point to the more
     detailed documentation and recommendations on how to address the
     problem above).

Any others?

Note, I'm not requesting any changes.  I'm just trying to understand if we
could/should establish guidelines for admin tasks requiring elevation.

> Having said that, if we want that I think the Vista elevation stuff
> should go into csih, rather than ssh-host-config script, so all admin
> scripts can use the functionality easily in the long run.

That certainly makes sense for admin scripts.  Though it would be good if
other admin commands would also behave similarly.

> And I'm sure Charles wouldn't mind to get csih patches ;)

Gots to understand the design goals before attempting any patches...

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Corinna Vinschen]

On Nov 19 17:38, Herb Maeder wrote:
> On 14 Nov 2008 10:53:12 +0100, Corinna Vinschen wrote:
> > Actually this isn't a ssh-host-config problem, but a generic problem
> > for all admin tasks.  Installing any service requires elevation, or
> > running in a Admin shell.  I'm not really convinced that we need it.
> > Admins running admin tasks should know that they need admin privileges.
> > What you're asking for is a convenience, not a necessity.
> 
> Yes, I agree that we are talking about a generic problem for tasks
> requiring elevation.  And perhaps I took it a step too far suggesting that
> we might want to provide a mechanism to elevate automatically (a lame
> attempt at being compatible with pre-vista OSes).  So I take that back.
> 
> I'd really just like to understand what the recommended behavior should be
> for admin tasks that are invoked from underprivileged shells under vista
> with UAC turned on.  In other words, should we do anything to ease a
> cygwin user's transition to Vista?
> 
> Right now, the documentation doesn't address any migration to vista
> issues.  So we are pretty much ensuring that new vista users will stumble
> onto the cygwin elevation problems the hard way.  And this list or its
> archives are the only resources to figure out what to do.  We can do
> better than that.
> 
> Bottom line, any design decision that reduces noise on this list will have
> the added benefit of providing a better experience to the user (win-win).
> Or put differently, an inconvience to the user can translate to an
> inconvenience to the list.
> 
> For example, would these be reasonable goals for admin tasks requiring
> elevation?
> 
>    * Provide documentation and recommendations for vista specific issues
>      (UAC recommendations, how to elevate, commands requiring
>      elevation,...).  Is the user guide the right place for that?
> 
>    * When a command requires elevation, detect if the process is already
>      elevated. If not, exit with an error and a reasonable error statement
>      indicating the nature of the problem (and perhaps point to the more
>      detailed documentation and recommendations on how to address the
>      problem above).
> 
> Any others?
> 
> Note, I'm not requesting any changes.  I'm just trying to understand if we
> could/should establish guidelines for admin tasks requiring elevation.

All nice points but I don't think that you have to convince anybody that
better documentation and scripts which work better in any environment
are preferrable.  The point is, http://cygwin.com/acronyms/#SHTDI
We can discuss stuff like that at great length but it won't help
anybody if the docs and code doesn't get fixed along these lines.

Be a part of the project and suggest documentation patches as you see
fit, or create code patches for scripts to make them more intelligent.
That would help other users and us maintainers a lot.  None of us has
access to all possible environments/systems and can care for all border
cases.  Or take the next step and be a maintainer yourself.  In most
cases it's not as much work in the long run as you think it is in the
beginning (when creating your package(s) the first time).

Talking about Vista migration.  From Cygwin's point of view Vista
is just another OS.  The user is just another user.  Either the user
has certain privileges or not.  A function works or returns EACCES.
That's all.  Elevation is not an issue for Cygwin, for pretty dumb
technical reasons.  The only concession *I* would be willing to make
(but that's just me) is to add some text to admin scripts along these
lines:

   *** Alarm!  I couldn't create file foo.
   *** You're missing privileges.  If you're admin user and running
   *** on Vista, did you think to run the script in an elevated shell?


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes.  I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
> 
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable.  The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.

OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage.  Witness the last guy who tried.

> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.

Um, that's what I was trying to do.  It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory.  I usually try to get agreement on a gameplan first, then
execute.

Lucky for me too, since what I saw fit was already wrong twice on this 
elevation issue...

> That would help other users and us maintainers a lot.  None of us has
> access to all possible environments/systems and can care for all border
> cases.  Or take the next step and be a maintainer yourself.  In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).

I'm probably not maintainer material.  I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package.  If you'd like to discuss it or convince me otherwise, you may
contact me personally.

> Talking about Vista migration.  From Cygwin's point of view Vista
> is just another OS.  The user is just another user.  Either the user
> has certain privileges or not.  A function works or returns EACCES.
> That's all.  Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons. 

Though it is an issue from the cygwin user's point of view.

But I do understand where you are coming from.  Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation).  Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...

> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
> 
>    *** Alarm!  I couldn't create file foo.
>    *** You're missing privileges.  If you're admin user and running
>    *** on Vista, did you think to run the script in an elevated shell?

That's actually decently close to what I was asking about.  Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go.  Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.

But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer.  And I'm fine with that, believe me.  An
answer is all I was looking for.   

So, to summarize this thread and move on:

  1) vista specific documentation is welcome
  2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
  3) patches for elevation issues are not

I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know.  Else, I'll just do as I see fit.

I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems.  So I can't commit to that
one.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes.  I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
> 
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable.  The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.

OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage.  Witness the last guy who tried.

> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.

Um, that's what I was trying to do.  It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory.  I usually try to get agreement on a gameplan first, then
execute.

Lucky for me too, since what I saw fit was already wrong twice on this 
elevation issue...

> That would help other users and us maintainers a lot.  None of us has
> access to all possible environments/systems and can care for all border
> cases.  Or take the next step and be a maintainer yourself.  In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).

I'm probably not maintainer material.  I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package.  If you'd like to discuss it or convince me otherwise, you may
contact me personally.

> Talking about Vista migration.  From Cygwin's point of view Vista
> is just another OS.  The user is just another user.  Either the user
> has certain privileges or not.  A function works or returns EACCES.
> That's all.  Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons. 

Though it is an issue from the cygwin user's point of view.

But I do understand where you are coming from.  Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation).  Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...

> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
> 
>    *** Alarm!  I couldn't create file foo.
>    *** You're missing privileges.  If you're admin user and running
>    *** on Vista, did you think to run the script in an elevated shell?

That's actually decently close to what I was asking about.  Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go.  Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.

But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer.  And I'm fine with that, believe me.  An
answer is all I was looking for.   

So, to summarize this thread and move on:

  1) vista specific documentation is welcome
  2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
  3) patches for elevation issues are not

I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know.  Else, I'll just do as I see fit.

I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems.  So I can't commit to that
one.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Matthew Woehlke]

Herb Maeder wrote:
> Any code requiring elevation is obviously already cygwin specific.

How so? There are tools on Linux that are only useful if run as root; 
how is that significantly different? (Especially on SELinux systems 
where rights are much more complicated than in the traditional UNIX model.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
C++ is for people who want to be able to not just shoot themselves in 
the foot, but do it with a rocket launcher. -- Igor Peshansky


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes.  I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
> 
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable.  The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.

OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage.  Witness the last guy who tried.

> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.

Um, that's what I was trying to do.  It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory.  I usually try to get agreement on a gameplan first, then
execute.

Lucky for me too, since what I saw fit was already wrong twice on this 
elevation issue...

> That would help other users and us maintainers a lot.  None of us has
> access to all possible environments/systems and can care for all border
> cases.  Or take the next step and be a maintainer yourself.  In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).

I'm probably not maintainer material.  I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package.  If you'd like to discuss it or convince me otherwise, you may
contact me personally.

> Talking about Vista migration.  From Cygwin's point of view Vista
> is just another OS.  The user is just another user.  Either the user
> has certain privileges or not.  A function works or returns EACCES.
> That's all.  Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons. 

Though it is an issue from the cygwin user's point of view.

But I do understand where you are coming from.  Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation).  Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...

> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
> 
>    *** Alarm!  I couldn't create file foo.
>    *** You're missing privileges.  If you're admin user and running
>    *** on Vista, did you think to run the script in an elevated shell?

That's actually decently close to what I was asking about.  Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go.  Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.

But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer.  And I'm fine with that, believe me.  An
answer is all I was looking for.   

So, to summarize this thread and move on:

  1) vista specific documentation is welcome
  2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
  3) patches for elevation issues are not

I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know.  Else, I'll just do as I see fit.

I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems.  So I can't commit to that
one.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes.  I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
> 
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable.  The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.

OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage.  Witness the last guy who tried.

> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.

Um, that's what I was trying to do.  It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory.  I usually try to get agreement on a gameplan first, then
execute.

Lucky for me too, since what I saw fit was already wrong twice on this 
elevation issue...

> That would help other users and us maintainers a lot.  None of us has
> access to all possible environments/systems and can care for all border
> cases.  Or take the next step and be a maintainer yourself.  In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).

I'm probably not maintainer material.  I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package.  If you'd like to discuss it or convince me otherwise, you may
contact me personally.

> Talking about Vista migration.  From Cygwin's point of view Vista
> is just another OS.  The user is just another user.  Either the user
> has certain privileges or not.  A function works or returns EACCES.
> That's all.  Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons. 

Though it is an issue from the cygwin user's point of view.

But I do understand where you are coming from.  Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation).  Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...

> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
> 
>    *** Alarm!  I couldn't create file foo.
>    *** You're missing privileges.  If you're admin user and running
>    *** on Vista, did you think to run the script in an elevated shell?

That's actually decently close to what I was asking about.  Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go.  Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.

But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer.  And I'm fine with that, believe me.  An
answer is all I was looking for.   

So, to summarize this thread and move on:

  1) vista specific documentation is welcome
  2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
  3) patches for elevation issues are not

I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know.  Else, I'll just do as I see fit.

I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems.  So I can't commit to that
one.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes.  I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
> 
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable.  The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.

OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage.  Witness the last guy who tried.

> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.

Um, that's what I was trying to do.  It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory.  I usually try to get agreement on a gameplan first, then
execute.

Lucky for me too, since what I saw fit was already wrong twice on this 
elevation issue...

> That would help other users and us maintainers a lot.  None of us has
> access to all possible environments/systems and can care for all border
> cases.  Or take the next step and be a maintainer yourself.  In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).

I'm probably not maintainer material.  I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package.  If you'd like to discuss it or convince me otherwise, you may
contact me personally.

> Talking about Vista migration.  From Cygwin's point of view Vista
> is just another OS.  The user is just another user.  Either the user
> has certain privileges or not.  A function works or returns EACCES.
> That's all.  Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons. 

Though it is an issue from the cygwin user's point of view.

But I do understand where you are coming from.  Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation).  Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...

> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
> 
>    *** Alarm!  I couldn't create file foo.
>    *** You're missing privileges.  If you're admin user and running
>    *** on Vista, did you think to run the script in an elevated shell?

That's actually decently close to what I was asking about.  Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go.  Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.

But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer.  And I'm fine with that, believe me.  An
answer is all I was looking for.   

So, to summarize this thread and move on:

  1) vista specific documentation is welcome
  2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
  3) patches for elevation issues are not

I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know.  Else, I'll just do as I see fit.

I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems.  So I can't commit to that
one.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes.  I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
> 
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable.  The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.

OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage.  Witness the last guy who tried.

> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.

Um, that's what I was trying to do.  It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory.  I usually try to get agreement on a gameplan first, then
execute.

Lucky for me too, since what I saw fit was already wrong twice on this 
elevation issue...

> That would help other users and us maintainers a lot.  None of us has
> access to all possible environments/systems and can care for all border
> cases.  Or take the next step and be a maintainer yourself.  In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).

I'm probably not maintainer material.  I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package.  If you'd like to discuss it or convince me otherwise, you may
contact me personally.

> Talking about Vista migration.  From Cygwin's point of view Vista
> is just another OS.  The user is just another user.  Either the user
> has certain privileges or not.  A function works or returns EACCES.
> That's all.  Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons. 

Though it is an issue from the cygwin user's point of view.

But I do understand where you are coming from.  Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation).  Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...

> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
> 
>    *** Alarm!  I couldn't create file foo.
>    *** You're missing privileges.  If you're admin user and running
>    *** on Vista, did you think to run the script in an elevated shell?

That's actually decently close to what I was asking about.  Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go.  Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.

But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer.  And I'm fine with that, believe me.  An
answer is all I was looking for.   

So, to summarize this thread and move on:

  1) vista specific documentation is welcome
  2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
  3) patches for elevation issues are not

I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know.  Else, I'll just do as I see fit.

I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems.  So I can't commit to that
one.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes.  I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
> 
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable.  The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.

OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage.  Witness the last guy who tried.

> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.

Um, that's what I was trying to do.  It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory.  I usually try to get agreement on a gameplan first, then
execute.

Lucky for me too, since what I saw fit was already wrong twice on this 
elevation issue...

> That would help other users and us maintainers a lot.  None of us has
> access to all possible environments/systems and can care for all border
> cases.  Or take the next step and be a maintainer yourself.  In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).

I'm probably not maintainer material.  I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package.  If you'd like to discuss it or convince me otherwise, you may
contact me personally.

> Talking about Vista migration.  From Cygwin's point of view Vista
> is just another OS.  The user is just another user.  Either the user
> has certain privileges or not.  A function works or returns EACCES.
> That's all.  Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons. 

Though it is an issue from the cygwin user's point of view.

But I do understand where you are coming from.  Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation).  Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...

> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
> 
>    *** Alarm!  I couldn't create file foo.
>    *** You're missing privileges.  If you're admin user and running
>    *** on Vista, did you think to run the script in an elevated shell?

That's actually decently close to what I was asking about.  Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go.  Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.

But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer.  And I'm fine with that, believe me.  An
answer is all I was looking for.   

So, to summarize this thread and move on:

  1) vista specific documentation is welcome
  2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
  3) patches for elevation issues are not

I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know.  Else, I'll just do as I see fit.

I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems.  So I can't commit to that
one.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: sshd on vista error "initgroups: Permission denied" (cygwin-1.7)

[Herb Maeder]

On 20 Nov 2008 11:37:23 +0100, Corinna Vinschen wrote:
> > Note, I'm not requesting any changes.  I'm just trying to understand if we
> > could/should establish guidelines for admin tasks requiring elevation.
> 
> All nice points but I don't think that you have to convince anybody that
> better documentation and scripts which work better in any environment
> are preferrable.  The point is, http://cygwin.com/acronyms/#SHTDI
> We can discuss stuff like that at great length but it won't help
> anybody if the docs and code doesn't get fixed along these lines.

OTOH, if you can't discuss stuff before patching, you're more likely to
get garbage.  Witness the last guy who tried.

> Be a part of the project and suggest documentation patches as you see
> fit, or create code patches for scripts to make them more intelligent.

Um, that's what I was trying to do.  It just that I'm not a big fan of the
"patch first, discuss later" philosophy, especially when I'm in unfamiliar
territory.  I usually try to get agreement on a gameplan first, then
execute.

Lucky for me too, since what I saw fit was already wrong twice on this 
elevation issue...

> That would help other users and us maintainers a lot.  None of us has
> access to all possible environments/systems and can care for all border
> cases.  Or take the next step and be a maintainer yourself.  In most
> cases it's not as much work in the long run as you think it is in the
> beginning (when creating your package(s) the first time).

I'm probably not maintainer material.  I don't care to discuss it on this
list, but it has nothing to do with the mechanics of maintaining a
package.  If you'd like to discuss it or convince me otherwise, you may
contact me personally.

> Talking about Vista migration.  From Cygwin's point of view Vista
> is just another OS.  The user is just another user.  Either the user
> has certain privileges or not.  A function works or returns EACCES.
> That's all.  Elevation is not an issue for Cygwin, for pretty dumb
> technical reasons. 

Though it is an issue from the cygwin user's point of view.

But I do understand where you are coming from.  Microsoft also took the
same approach (nothing was done to ease the pain of using Windows command
line tools requiring elevation).  Not that that necessarily makes it
http://acronyms.thefreedictionary.com/TRTTD ...

> The only concession *I* would be willing to make
> (but that's just me) is to add some text to admin scripts along these
> lines:
> 
>    *** Alarm!  I couldn't create file foo.
>    *** You're missing privileges.  If you're admin user and running
>    *** on Vista, did you think to run the script in an elevated shell?

That's actually decently close to what I was asking about.  Though the
error statement could be qualified with (onVista && !elevated), and some
scripts which don't make sense without elevation (e.g. ssh-host-config)
could just test for that right from the get-go.  Plus there's no reason
that compiled commands couldn't do something similar (e.g. "regtool add").
Any code requiring elevation is obviously already cygwin specific.

But, it sounds to me like that is not worth doing and/or not desirable.
That's a perfectly good answer.  And I'm fine with that, believe me.  An
answer is all I was looking for.   

So, to summarize this thread and move on:

  1) vista specific documentation is welcome
  2) patches to csih/ssh-host-config for 1.7+vista+domain users are welcome
  3) patches for elevation issues are not

I'm willing to take a whack at 1), so if anyone has any specific topics
that should be covered or any hints on where this documentation belongs,
please let me know.  Else, I'll just do as I see fit.

I sould also like to address 2), but I am now in the boat of not having
access to the required environments/systems.  So I can't commit to that
one.

Herb.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Does CYGWIN work on Windows 2008 x86 architecture ?

[Freddy Jensen]

   >From: Corinna Vinschen <corinna-cygwin@cygwin.com>
   >Date: Mon Feb 16 2009  3:07am
   >To:   "cygwin@cygwin.com" <cygwin@cygwin.com>
   >Subj: Re: Does CYGWIN work on Windows 2008 x86 architecture ?
   >
   >On Feb 16 11:05, Martine Carannante wrote:
   >> Hi
   >>
   >> I try again to ask if someone has installed CYGWIN on Windows 2008 x86 
   >> architecture.
   >>
   >> It works fine on x64 architecture but bash  fails on X86 like this
   >> bash
   >>     2 [main] bash 3520 _cygtls::handle_exceptions: Exception: 
   >> STATUS_ACCESS_VIOLATION
   >>   315 [main] bash 3520 open_stackdumpfile: Dumping stack trace to 
   >> bash.exe.stackdump
   >> 430671 [main] bash 3520 _cygtls::handle_exceptions: Exception: 
   >> STATUS_ACCESS_VIOLATION
   >> 448747 [main] bash 3520 _cygtls::handle_exceptions: Error while dumping 
   >> state (
   >> probably corrupted stack)
   >>
   >> I have not found an answer in the cygwin mailing list.
   >
   >Works fine for me.  Except in one case:
   >http://cygwin.com/ml/cygwin/2008-10/msg00459.html
   >
   >I opened a support case at Microsoft but it has been refused.
   >
   >Since the problem occurs in a Microsoft DLL, we have no way to fix it
   >in Cygwin.  Cygwin 1.7 has a crude workaround for this situation,
   >though.  So your choices are
   >
   >- Deinstall Terminal Services entirely
   >- Switch off DEP
   >- Use Cygwin 1.7 (still in TEST for another few weeks)
   >
   >If it's not TS, it's probably a case of
   >http://cygwin.com/acronyms/#BLODA
   >
   >Corinna
   >
   >-- 
   >Corinna Vinschen                  Please, send mails regarding Cygwin to
   >Cygwin Project Co-Leader          cygwin AT cygwin DOT com
   >Red Hat
   >

For me it works with pre-1.7 versions of cygwin as long as I have
switched off DEP and uninstallled Terminal Services.

I think the problem is independent of whether it is x86 or x64 because
for me the problem occurs on x64.

Thanks

Freddy

--
Freddy Jensen, Sr. Computer Scientist, Adobe Systems Incorporated
345 Park Avenue, San Jose, CA 95110-2704, USA, Ph: (408) 536-2869
Email: jensen@adobe.com, URL: http://www.adobe.com
--


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Cygwin apps talking to Windows browsers?

[andrew brian clegg]

I'm no expert on how to do this in mh-e but speaking of the general case,
there's no particular jiggery-pokery needed to get a Cygwin app to launch
a URL in a Windows browser.

e.g. try typing

explorer "http://www.google.com/"

from your bash prompt, or if you want your default Windows URL handler to
handle it by magic, you can do

cmd /c start "http://www.google.com"

(the start trick works in Win2K and XP, not sure about DOS-style Windows).

Assuming mh-e has a configuration option that lets you give it a command
string to execute with a %s or whatever where the URL should be, one of
those approaches should do the trick.

As far as clicking on a URL in a remote app and having it display in a
local Windows browser goes... Pass. Anyone else?

Andrew.

On Thu, 10 Jul 2003, Jeffrey C Honig wrote:

> Date: Thu, 10 Jul 2003 11:32:59 -0400
> From: Jeffrey C Honig <jch@honig.net>
> To: cygwin@cygwin.com
> Subject: Cygwin apps talking to Windows browsers?
> 
> I use emacs under Cygwin (with Cygwin/XFree86 and/or Exceed) and would
> like to switch to using mh-e in this environment.
> 
> One thing that I would like to do is to be able to click on a URL and
> have my Windows browser (in this case Opera) be told to open the page.
> Is there an app to allow this?
> 
> How about an app that would allow this from emacs running on another
> host via X?
> 
> If there is no APP for this, is there an API for it?
> 
> Thanks.
> 
> Jeff
> 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Cygwin apps talking to Windows browsers? openmoz for file URLs

[Ralf Hauser]

...
> there's no particular jiggery-pokery needed to get a Cygwin app to launch
> a URL in a Windows browser.
>
> e.g. try typing
>
> explorer "http://www.google.com/"
>
> from your bash prompt, or if you want your default Windows URL handler to
> handle it by magic, you can do
>
> cmd /c start "http://www.google.com"
>
> (the start trick works in Win2K and XP, not sure about DOS-style Windows).

have a look at http://ostermiller.org/openmoz/ - especially since that
script also handles file URLs

I did some minor changes and now it also should run under cygwin
--> https://p4u.ch/public/cygwin_usr_local_bin/openmoz.sh


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Cygwin apps talking to Windows browsers?

[Scott W Brim]

Hi Jeff.

On Thu, Jul 10, 2003 11:32:59AM -0400, Jeffrey C Honig allegedly wrote:
> I use emacs under Cygwin (with Cygwin/XFree86 and/or Exceed) and would
> like to switch to using mh-e in this environment.

The last I heard getting nmh working wasn't easy.  Have you done it?

> One thing that I would like to do is to be able to click on a URL and
> have my Windows browser (in this case Opera) be told to open the page.
> Is there an app to allow this?
>
> How about an app that would allow this from emacs running on another
> host via X?

Also check out browse-url.el.  I have

  (setq browse-url-browser-function 'browse-url-default-windows-browser)

in .emacs for windows; it could be set conditional to system type.

..Scott

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Does CYGWIN work on Windows 2008 x86 architecture ?

[Martine Carannante]

Hi

I try again to ask if someone has installed CYGWIN on Windows 2008 x86 
architecture.

It works fine on x64 architecture but bash  fails on X86 like this
bash
     2 [main] bash 3520 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
   315 [main] bash 3520 open_stackdumpfile: Dumping stack trace to 
bash.exe.stackdump
430671 [main] bash 3520 _cygtls::handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
448747 [main] bash 3520 _cygtls::handle_exceptions: Error while dumping 
state (
probably corrupted stack)

I have not found an answer in the cygwin mailing list.

Could you help me ?
Thanks in advance.
Martine

-- 
Martine Carannante
System Software Development R&D 

Bull, Architect of an Open World TM 

Tél : (+33) 1 30 80 71 87
http://www.bull.com 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Does CYGWIN work on Windows 2008 x86 architecture ?

[Corinna Vinschen]

On Feb 16 11:05, Martine Carannante wrote:
> Hi
>
> I try again to ask if someone has installed CYGWIN on Windows 2008 x86 
> architecture.
>
> It works fine on x64 architecture but bash  fails on X86 like this
> bash
>     2 [main] bash 3520 _cygtls::handle_exceptions: Exception: 
> STATUS_ACCESS_VIOLATION
>   315 [main] bash 3520 open_stackdumpfile: Dumping stack trace to 
> bash.exe.stackdump
> 430671 [main] bash 3520 _cygtls::handle_exceptions: Exception: 
> STATUS_ACCESS_VIOLATION
> 448747 [main] bash 3520 _cygtls::handle_exceptions: Error while dumping 
> state (
> probably corrupted stack)
>
> I have not found an answer in the cygwin mailing list.

Works fine for me.  Except in one case:
http://cygwin.com/ml/cygwin/2008-10/msg00459.html

I opened a support case at Microsoft but it has been refused.

Since the problem occurs in a Microsoft DLL, we have no way to fix it
in Cygwin.  Cygwin 1.7 has a crude workaround for this situation,
though.  So your choices are

- Deinstall Terminal Services entirely
- Switch off DEP
- Use Cygwin 1.7 (still in TEST for another few weeks)

If it's not TS, it's probably a case of
http://cygwin.com/acronyms/#BLODA


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Does CYGWIN work on Windows 2008 x86 architecture ?

[Martine Carannante]

Thanks a lot
Martine

Corinna Vinschen wrote:

>On Feb 16 11:05, Martine Carannante wrote:
>  
>
>>Hi
>>
>>I try again to ask if someone has installed CYGWIN on Windows 2008 x86 
>>architecture.
>>
>>It works fine on x64 architecture but bash  fails on X86 like this
>>bash
>>    2 [main] bash 3520 _cygtls::handle_exceptions: Exception: 
>>STATUS_ACCESS_VIOLATION
>>  315 [main] bash 3520 open_stackdumpfile: Dumping stack trace to 
>>bash.exe.stackdump
>>430671 [main] bash 3520 _cygtls::handle_exceptions: Exception: 
>>STATUS_ACCESS_VIOLATION
>>448747 [main] bash 3520 _cygtls::handle_exceptions: Error while dumping 
>>state (
>>probably corrupted stack)
>>
>>I have not found an answer in the cygwin mailing list.
>>    
>>
>
>Works fine for me.  Except in one case:
>http://cygwin.com/ml/cygwin/2008-10/msg00459.html
>
>I opened a support case at Microsoft but it has been refused.
>
>Since the problem occurs in a Microsoft DLL, we have no way to fix it
>in Cygwin.  Cygwin 1.7 has a crude workaround for this situation,
>though.  So your choices are
>
>- Deinstall Terminal Services entirely
>- Switch off DEP
>- Use Cygwin 1.7 (still in TEST for another few weeks)
>
>If it's not TS, it's probably a case of
>http://cygwin.com/acronyms/#BLODA
>
>
>Corinna
>
>  
>


-- 
Martine Carannante
System Software Development R&D 

Bull, Architect of an Open World TM 

Tél : (+33) 1 30 80 71 87
http://www.bull.com 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Does CYGWIN work on Windows 2008 x86 architecture ?

[Ben Kamen]

Corinna Vinschen wrote:
> Works fine for me.  Except in one case:
> http://cygwin.com/ml/cygwin/2008-10/msg00459.html
>
> I opened a support case at Microsoft but it has been refused.
>
> Since the problem occurs in a Microsoft DLL, we have no way to fix it
> in Cygwin.  Cygwin 1.7 has a crude workaround for this situation,
> though.  So your choices are
>
>   

Boy if that doesn't smack of monopoly abuse. Brings back memories of 
DR-DOS and others.

 -Ben




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

cygwin bash crashes on Win Serv 2008

[Freddy Jensen]

Apparently the cygwin bash crash on Win Serv 2008 is related to the
"Terminal Services" on Windows. It looks like the problem is not
there if the Terminal Services has not been installed/started.

I make that conclusion because I have a co-worker who has the exact
same configuration as me, the only difference being that he does
not have the terminal services installed and cygwin works fine on
his machine.

Furthermore, I found these postings that describe the same
problem (see attached below).

As you can see, all the postinstall scripts fail because they are
sh scripts and bash (sh) cannot run. This explains why many more
cygwin commands don't work in this scenario, for example grep,
man, ...etc.  Apparently some commands require some postinstall
scripts to finish the install and other commands do not require
any postinstall fixups. So only the commands that depend on a
successful run of the postinstall scripts will fail in this
scenario. For example 'ls' and 'mkdir' work ok, apparently
because they are simple enough that they don't depend on any
postinstall things.

Thanks

Freddy


========== Begin included message ==========

grep exit with STATUS_ACCESS_VIOLATION error:

When I try to make Portable Cygwin running from USB, I using batch
script to install cygwin automatically and call sh script to make cygwin
user account. Unfortunately after several test and tunning my script
exited with STATUS_ACCESS_VIOLANTION error and make system unstable.
When i try to run my script again unfortunately i can't reproduce this
error again for further investigation. I wonder if it's just temporary
error or some thing wrong with my script, also maybe some one can give
me suggestion to improve my script.

I run cygwin 1.5.25 in Windows XP 2002 SP2 with Intel Pentium MMX 250
MHz with 128 ram

Hello,

I've just installed Cygwin on two different Windows 2008 machines, one of t=
hem is running Terminal Services, and the other without.

The system without Terminal Services runs fine with Cygwin, with the same i=
nstall options.
The system with Terminal Services does not run, and produces the following =
errors:



C:\cygwin\bin>bash.exe --version
     14 [main] bash 1732 _cygtls::handle_exceptions: Exception: STATUS_ACCE=
SS_VIOLATION
   1255 [main] bash 1732 open_stackdumpfile: Dumping stack trace to bash.ex=
e.stackdump
 197760 [main] bash 1732 _cygtls::handle_exceptions: Exception: STATUS_ACCE=
SS_VIOLATION
 200075 [main] bash 1732 _cygtls::handle_exceptions: Error while dumping st=
ate (probably corrupted stack)
C:\cygwin\bin>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Problems installing Cygwin 1.5.25-15 onto base Windows Server2008 w/Termina=
l Services installed
Click to flag this post

by Brett Carey Oct 15, 2008; 01:51pm :: Rate this Message: - Use ratings to=
 moderate (?)

Reply | Reply to Author | Print | View Threaded | Show Only this Message
Background:
Attempting to use a Windows Server 2008 64-bit Terminal server as a "Jump-B=
ox" from one network (corporate very locked down and restricted software) t=
o another (lab servers and QA and development). I figure if I put the neces=
sary software on the 'Jump-Box' and grant users the ability to remote deskt=
op in, they will be able to use the software they need without the need for=
 2 separate machines (one for corporate, one for the lab servers). Since my=
 users will need to connect to Linux servers and Windows does not have a bu=
ilt in ssh or scp I needed a solution. I've used Cygwin in the past and by =
putting C:\cygwin\bin into the environmental path I was able to ssh and scp=
 right from the command (DOS) box. Simple, easy, cake.

Attempting to install Cygwin 1.5.25-15 (fresh download from ftp.gtlib.gatec=
h.edu, base install) on the 'Jump-Box' from RDP (Remote Desktop) as a user =
with full Administrators permissions appears to complete but looking at the=
 log it seems all the postinstall scripts failed (see attachments: FAILsetu=
p.log and FAILsetup.log.full). Attempting the install from the console as A=
dministrator generates the same results. As a result the functionality I'm =
looking for is not working. I've done extensive searches and find very litt=
le information on those errors, my problem or any solution.

Snippet from FAILsetup.log:
2008/10/15 15:14:40 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/upd=
ate-info-dir.sh
2008/10/15 15:14:41 abnormal exit: exit code=3D35584
2008/10/15 15:14:41 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/cor=
eutils.sh
2008/10/15 15:14:41 abnormal exit: exit code=3D35584
2008/10/15 15:14:41 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/ter=
minfo.sh
2008/10/15 15:14:41 abnormal exit: exit code=3D35584

Snippet from FAILsetup.log.full:
2008/10/15 15:14:40 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/upd=
ate-info-dir.sh
      5 [main] bash 5088 _cygtls::handle_exceptions: Exception: STATUS_ACCE=
SS_VIOLATION
  22633 [main] bash 5088 open_stackdumpfile: Dumping stack trace to bash.ex=
e.stackdump
2008/10/15 15:14:41 abnormal exit: exit code=3D35584
2008/10/15 15:14:41 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/cor=
eutils.sh
      2 [main] bash 4572 _cygtls::handle_exceptions: Exception: STATUS_ACCE=
SS_VIOLATION
    803 [main] bash 4572 open_stackdumpfile: Dumping stack trace to bash.ex=
e.stackdump
2008/10/15 15:14:41 abnormal exit: exit code=3D35584
2008/10/15 15:14:41 running: C:\cygwin\bin\bash.exe -c /etc/postinstall/ter=
minfo.sh
      2 [main] bash 2896 _cygtls::handle_exceptions: Exception: STATUS_ACCE=
SS_VIOLATION
    798 [main] bash 2896 open_stackdumpfile: Dumping stack trace to bash.ex=
e.stackdump

========== End included message ==========


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bash crashes on Win Serv 2008

[Corinna Vinschen]

On Oct 20 14:42, Freddy Jensen wrote:
> 
> Apparently the cygwin bash crash on Win Serv 2008 is related to the
> "Terminal Services" on Windows. It looks like the problem is not
> there if the Terminal Services has not been installed/started.

I can confirm this observation.  It doesn't matter if the TS services
are started or not.  Just by having TS installed, certain Cygwin
processes crash.  In my case I can observe crashes in bash, grep, and
GDB, as soon as TS is installed.  However, other applications run fine,
tcsh, vim, all from coreutils as far as I can see...

The crashes don't occur in Cygwin, but in the application code.  As I
said, one of the crashing apps is bash.  I created a full debug bash
version and a special debug version of GDB which, for some reason, runs
fine, in contrast to the net release version of GDB.  What happens is
that some arbitrary application function is called from main() and the
first instruction in this function is the opcode for storing the frame
pointer on the stack, `push %ebp'.  This is, in theory, an entirely
harmless operation.  The stack and register content before and after the
crash are looking absolutely normal.  The push does neither operate on
an invalid address nor on a page boundary, nor is it misaligned.  It's
just a push to some arbitrary address within an existing stack page.

Another strange effect is that even teeny little changes to the
application code (adding a `puts("hello");' or something) result in
entirely different function calls to crash.  The only constant factor is
that it's always the first assembler instruction in some application
function.

For testing I tried to disabled SEH and the Ctrl-C handler in Cygwin,
but the crashes persist.

This puzzles me no end.  Here's the only way I found so far to get rid
of the crashes: Remove Terminal Services and reboot the machine.
Reinstall TS and you're back to square one.


Any hints or help to debug this weird phenomenon are gratefully
appreciated.


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bash crashes on Win Serv 2008

[Corinna Vinschen]

On Oct 23 15:54, Corinna Vinschen wrote:
> On Oct 20 14:42, Freddy Jensen wrote:
> > 
> > Apparently the cygwin bash crash on Win Serv 2008 is related to the
> > "Terminal Services" on Windows. It looks like the problem is not
> > there if the Terminal Services has not been installed/started.
> 
> I can confirm this observation.  It doesn't matter if the TS services
> are started or not.  Just by having TS installed, certain Cygwin
> processes crash.  In my case I can observe crashes in bash, grep, and
> GDB, as soon as TS is installed.  However, other applications run fine,
> tcsh, vim, all from coreutils as far as I can see...
> 
> The crashes don't occur in Cygwin, but in the application code.  As I
> said, one of the crashing apps is bash.  I created a full debug bash
> version and a special debug version of GDB which, for some reason, runs
> fine, in contrast to the net release version of GDB.  What happens is
> that some arbitrary application function is called from main() and the
> first instruction in this function is the opcode for storing the frame
> pointer on the stack, `push %ebp'.

I seem to have missed the point here.  The point is, this `push %ebp'
instruction is the one crashing, producing a segmentation violation.

>   This is, in theory, an entirely
> harmless operation.  The stack and register content before and after the
> crash are looking absolutely normal.  The push does neither operate on
> an invalid address nor on a page boundary, nor is it misaligned.  It's
> just a push to some arbitrary address within an existing stack page.
> 
> Another strange effect is that even teeny little changes to the
> application code (adding a `puts("hello");' or something) result in
> entirely different function calls to crash.  The only constant factor is
> that it's always the first assembler instruction in some application
> function.
> 
> For testing I tried to disabled SEH and the Ctrl-C handler in Cygwin,
> but the crashes persist.
> 
> This puzzles me no end.  Here's the only way I found so far to get rid
> of the crashes: Remove Terminal Services and reboot the machine.
> Reinstall TS and you're back to square one.
> 
> 
> Any hints or help to debug this weird phenomenon are gratefully
> appreciated.
> 
> 
> Corinna
> 
> -- 
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader          cygwin AT cygwin DOT com
> Red Hat
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: cygwin bash crashes on Win Serv 2008

[Dave Korn]

Corinna Vinschen wrote on 23 October 2008 15:09:

>> The crashes don't occur in Cygwin, but in the application code.  As I
>> said, one of the crashing apps is bash.  I created a full debug bash
>> version and a special debug version of GDB which, for some reason, runs
>> fine, in contrast to the net release version of GDB.  What happens is
>> that some arbitrary application function is called from main() and the
>> first instruction in this function is the opcode for storing the frame
>> pointer on the stack, `push %ebp'.
> 
> I seem to have missed the point here.  The point is, this `push %ebp'
> instruction is the one crashing, producing a segmentation violation.

  What's the underlying windows exception (i.e. before cygwin translates that
into SEGV)?  

> 
>>   This is, in theory, an entirely
>> harmless operation.  The stack and register content before and after the
>> crash are looking absolutely normal.  The push does neither operate on
>> an invalid address nor on a page boundary, nor is it misaligned.  It's
>> just a push to some arbitrary address within an existing stack page.

  Only thing I can think of is "Not if %ss has been mucked around with it
isn't".

  I'd use windbg on this, take a look at the exception record and selectors
and stuff.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bash crashes on Win Serv 2008

[Corinna Vinschen]

On Oct 23 16:40, Dave Korn wrote:
> Corinna Vinschen wrote on 23 October 2008 15:09:
> > I seem to have missed the point here.  The point is, this `push %ebp'
> > instruction is the one crashing, producing a segmentation violation.
> 
>   What's the underlying windows exception (i.e. before cygwin translates that
> into SEGV)?  

STATUS_ACCESS_VIOLATION

> >>   This is, in theory, an entirely
> >> harmless operation.  The stack and register content before and after the
> >> crash are looking absolutely normal.  The push does neither operate on
> >> an invalid address nor on a page boundary, nor is it misaligned.  It's
> >> just a push to some arbitrary address within an existing stack page.
> 
>   Only thing I can think of is "Not if %ss has been mucked around with it
> isn't".

Yeah, I heard about that.  But what is %ss doing in Windows and why
should it be messed up with TS?!?  And why are only Cygwin processes
affected, and then only some?

>   I'd use windbg on this, take a look at the exception record and selectors
> and stuff.

The exception record was a good hint (I don't know what you mean by
"selectors", sorry).  Unfortunately it puzzles me even more:

    ExceptionAddress: 00419d97 (image00400000+0x00019d97)
       ExceptionCode: c0000005 (Access violation)
      ExceptionFlags: 00000000
    NumberParameters: 2
       Parameter[0]: 00000008
       Parameter[1]: 00419d97
    Attempt to execute non-executable address 00419d97

Huh?  Why should this address (this application function) be
"non-executable", while it's executable when TS is not installed?

Could this have something to do with the executbale header gcc creates?
If so, maybe mingw apps are affected as well...


Thanks,
Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: cygwin bash crashes on Win Serv 2008

[Dave Korn]

Corinna Vinschen wrote on 23 October 2008 17:21:

>>   Only thing I can think of is "Not if %ss has been mucked around with it
>> isn't".
> 
> Yeah, I heard about that.  But what is %ss doing in Windows 

  Same as usual.  Pointing to the stack segment.  It just /happens/ that the
SS is a full 32-bit flat mapping of the same virtual memory space as %cs, %ds,
etc,. but it doesn't (in theory) have to be.

> and why should it be messed up with TS?!?  

  Extra security measures turned on by default on multi-user servers that are
turned off by default usually?

> And why are only Cygwin processes affected, and then only some?

  Just lucky, I guess...


>>   I'd use windbg on this, take a look at the exception record and
>> selectors and stuff.
> 
> The exception record was a good hint (I don't know what you mean by
> "selectors", sorry).  

  See the "dg" command, e.g. "dg %cs", "dg %ds", "dg %ss".

> Unfortunately it puzzles me even more:
> 
>     ExceptionAddress: 00419d97 (image00400000+0x00019d97)
>        ExceptionCode: c0000005 (Access violation)
>       ExceptionFlags: 00000000
>     NumberParameters: 2
>        Parameter[0]: 00000008
>        Parameter[1]: 00419d97
>     Attempt to execute non-executable address 00419d97
> 
> Huh?  Why should this address (this application function) be
> "non-executable", while it's executable when TS is not installed?

  DEP?  ASLR?  SafeSEH?  As well as "dg" there are some other commands in
windbg that'll show you memory types and attributes.

> Could this have something to do with the executbale header gcc creates?

  Dunno - which executable header?  Seems unlikely since we're in a completely
different memory page and well beyond the header area into the .text segment.

  (Actually, are we in the .text segment, or is there a thunk of some kind in
.rdata?  And is the difference perhaps related to the use-or-not, or the
need-for-or-not, of ld's --{en,dis}able-runtime-pseudo-reloc options?)

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bash crashes on Win Serv 2008

[Freddy Jensen]

I forgot to mention that for us, it happens on a 64-bit version
of Win Serv 2008. We have not tried it on a 32-bit version.

Freddy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: cygwin bash crashes on Win Serv 2008

[Dave Korn]

Freddy Jensen wrote on 23 October 2008 18:00:

> I forgot to mention that for us, it happens on a 64-bit version
> of Win Serv 2008. We have not tried it on a 32-bit version.


  I believe that would suggest this is a side-effect of DEP being opt-out by
default on win64 and opt-in by default on win32, no?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bash crashes on Win Serv 2008

[Corinna Vinschen]

On Oct 23 17:52, Dave Korn wrote:
> Corinna Vinschen wrote on 23 October 2008 17:21:
> >     Attempt to execute non-executable address 00419d97
> > 
> > Huh?  Why should this address (this application function) be
> > "non-executable", while it's executable when TS is not installed?
> 
>   DEP?  ASLR?  SafeSEH?  As well as "dg" there are some other commands in
> windbg that'll show you memory types and attributes.

Huh!  It was DEP.  Apparently when installing TS, the default setting
for DEP is switched from "Turn on DEP for essential Windows programs
and services only" to "Turn on DEP for all programs and services
[with execptions]".  I switched it back, rebooted, and now bash, grep
and GDB work fine.

However, I don't understand why this happens.  The address in question
(419d97) is well within the .text segment:

  .text    401000 -> 46a510
  .data    46b000 -> 46d380

As for ASLR and SafeSEH, both functions are, afaik, only enabled if you
set a flag in the Windows specifc extended PE/COFF header.

And there's something else I don't get.  DEP is usually no problem when
running apps from the Cygwin net distro.  And if I enable DEP but TS
is not installed, bash and friends run fine.  Only the combination of
TS *and* DEP results in a crash.  If I exclude bash.exe explicitly, no
crash in bash.  Unfortunately it's not possible to exclude cygwin1.dll
and then all Cygwin apps magically work.

> > Could this have something to do with the executbale header gcc creates?
> 
>   Dunno - which executable header?  Seems unlikely since we're in a completely
> different memory page and well beyond the header area into the .text segment.

I mean the flags you can set in the extended PE/COFF header.

>   (Actually, are we in the .text segment, or is there a thunk of some kind in
> .rdata?  And is the difference perhaps related to the use-or-not, or the
> need-for-or-not, of ld's --{en,dis}able-runtime-pseudo-reloc options?)

There is a .rdata, but the function address is in .text and it has
been called by a simple call instruction from main(), also well within
the .text segment.

Thanks for the DEP hint.  So that's the (temporary?) solution for now,
don't enforce DEP on Cygwin apps when TS is installed.  But it's still
unclear to me why TS plus DEP would have an effect on an innocent
application like bash at all.


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bash crashes on Win Serv 2008

[Corinna Vinschen]

FYI, Microsoft Professional Support EMEA didn't accept this problem as a
support case.  So, if nobody at Microsoft thinks this is a potential OS
problem and requires analyzing from the OS side, it will stay unfixed.

On Oct 23 20:53, Corinna Vinschen wrote:
> On Oct 23 17:52, Dave Korn wrote:
> > Corinna Vinschen wrote on 23 October 2008 17:21:
> > >     Attempt to execute non-executable address 00419d97
> > > 
> > > Huh?  Why should this address (this application function) be
> > > "non-executable", while it's executable when TS is not installed?
> > 
> >   DEP?  ASLR?  SafeSEH?  As well as "dg" there are some other commands in
> > windbg that'll show you memory types and attributes.
> 
> Huh!  It was DEP.  Apparently when installing TS, the default setting
> for DEP is switched from "Turn on DEP for essential Windows programs
> and services only" to "Turn on DEP for all programs and services
> [with execptions]".  I switched it back, rebooted, and now bash, grep
> and GDB work fine.

Apparently Server 2008 has DEP switched on by default.  I missed this
when testing but the MS support engineer told me.  Of course that
doesn't change the fact that bash/gdb/grep work fine with DEP switched
on as long as TS isn't installed...


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: cygwin bash crashes on Win Serv 2008

[EMF]

Hmm... this sounds like it might also be the case with the Citrix and
Exchange boxes I was dealing with in the thread "Terminal Services session
hung: csrss.exe doesn't exit if Cygwin was run in the session".  I'll have
to go back and look at those, even though I've rebuilt those projects with
other tools.

(Did I mention I really like Cygwin, and don't want to have to give it up?
Yeah, I think so. ;D)

-- Eric

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of
Corinna Vinschen
Sent: Thursday, October 23, 2008 2:54 PM
To: cygwin@cygwin.com
Subject: Re: cygwin bash crashes on Win Serv 2008

On Oct 23 17:52, Dave Korn wrote:
> Corinna Vinschen wrote on 23 October 2008 17:21:
> >     Attempt to execute non-executable address 00419d97
> > 
> > Huh?  Why should this address (this application function) be
> > "non-executable", while it's executable when TS is not installed?
> 
>   DEP?  ASLR?  SafeSEH?  As well as "dg" there are some other commands in
> windbg that'll show you memory types and attributes.

Huh!  It was DEP.  Apparently when installing TS, the default setting
for DEP is switched from "Turn on DEP for essential Windows programs
and services only" to "Turn on DEP for all programs and services
[with execptions]".  I switched it back, rebooted, and now bash, grep
and GDB work fine.

However, I don't understand why this happens.  The address in question
(419d97) is well within the .text segment:

  .text    401000 -> 46a510
  .data    46b000 -> 46d380

As for ASLR and SafeSEH, both functions are, afaik, only enabled if you
set a flag in the Windows specifc extended PE/COFF header.

And there's something else I don't get.  DEP is usually no problem when
running apps from the Cygwin net distro.  And if I enable DEP but TS
is not installed, bash and friends run fine.  Only the combination of
TS *and* DEP results in a crash.  If I exclude bash.exe explicitly, no
crash in bash.  Unfortunately it's not possible to exclude cygwin1.dll
and then all Cygwin apps magically work.

> > Could this have something to do with the executbale header gcc creates?
> 
>   Dunno - which executable header?  Seems unlikely since we're in a
completely
> different memory page and well beyond the header area into the .text
segment.

I mean the flags you can set in the extended PE/COFF header.

>   (Actually, are we in the .text segment, or is there a thunk of some kind
in
> .rdata?  And is the difference perhaps related to the use-or-not, or the
> need-for-or-not, of ld's --{en,dis}able-runtime-pseudo-reloc options?)

There is a .rdata, but the function address is in .text and it has
been called by a simple call instruction from main(), also well within
the .text segment.

Thanks for the DEP hint.  So that's the (temporary?) solution for now,
don't enforce DEP on Cygwin apps when TS is installed.  But it's still
unclear to me why TS plus DEP would have an effect on an innocent
application like bash at all.


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin bash crashes on Win Serv 2008

[Christopher Faylor]

On Fri, Oct 31, 2008 at 12:30:22AM -0400, EMF wrote:
>(Did I mention I really like Cygwin, and don't want to have to give it up?
>Yeah, I think so. ;D)
>
>-----Original Message-----
>From: cygwin-owner@XXXX [mailto:cygwin-owner@XXx] On Behalf Of
>Corinna Vinschen
>Sent: Thursday, October 23, 2008 2:54 PM
>To: cygwin@XXXX
>Subject: Re: cygwin bash crashes on Win Serv 2008

If you really like Cygwin then maybe you'll do us the favor of honoring
the conventions of the Cygwin mailing list and stop pointlessly adding
header information in the body of your email.  There really is no reason
for this duplication and it only serves to feed the spammers.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: cygwin bash crashes on Win Serv 2008

[EMF]

> If you really like Cygwin then maybe you'll do us the favor of honoring
> the conventions of the Cygwin mailing list and stop pointlessly adding
> header information in the body of your email.  There really is no reason
> for this duplication and it only serves to feed the spammers.

And maybe instead of trying to pay a thankful compliment to the maintainers
of the project, I'll just keep my trap shut for the abuse on an oversight.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: problems with exit codes on 64-bit Windows XP Pro x64

[Kevin Layer]

[Interestingly, the text of my message was stripped out... here it is]

I'm running the latest cygwin (1.5.19, see cygcheck below).

My application is a native Windows app (64 and 32-bit).  It includes
no cygwin libraries and is not compiled with cygwin's gcc.  When I
execute cygwin programs from my app, however, the return value
obtained from cygwin programs is always 0.

More precisely, I spawn a particular cygwin program, say `make' or
`sh', with CreateProcess().  When the program exits
GetExitCodeProcess() always sets the exit status to 0, no matter what
the real exit status was.

Attached are 2 programs, exit1.c and bug.c.  Compile with:

cl bug.c bufferoverflowu.lib
cl exit1.c bufferoverflowu.lib

[cl is MS C/C++ version 14, found in the SDK.]

Then, running on 64-bit windows:

  ./bug exit1
  result = 0

Doing the experimentn on 32-bit Windows gets the output

  result = 1

Below are the files.

Is this a known issue?  Any chance of a fix?

-- 
Kevin Layer             layer@Franz.COM        http://www.franz.com/
Franz Inc., 555 12th St., Suite 1450, Oakland, CA  94607, USA
Phone: (510) 452-2000   FAX: (510) 452-0182


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: problems with exit codes on 64-bit Windows XP Pro x64

[Corinna Vinschen]

On Feb  6 14:49, Kevin Layer wrote:
> I'm running the latest cygwin (1.5.19, see cygcheck below).
> 
> My application is a native Windows app (64 and 32-bit).  It includes
> no cygwin libraries and is not compiled with cygwin's gcc.  When I
> execute cygwin programs from my app, however, the return value
> obtained from cygwin programs is always 0.
> 
> More precisely, I spawn a particular cygwin program, say `make' or
> `sh', with CreateProcess().  When the program exits
> GetExitCodeProcess() always sets the exit status to 0, no matter what
> the real exit status was.

I just applied a patch which should return the correct error code.

Thanks for the testcase, it's highly appreciated, though... it was
a lot of code for emulating cmd's "echo %errorlevel%" ;-)


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: problems with exit codes on 64-bit Windows XP Pro x64

[Corinna Vinschen]

On Feb  7 11:01, Corinna Vinschen wrote:
> On Feb  6 14:49, Kevin Layer wrote:
> > I'm running the latest cygwin (1.5.19, see cygcheck below).
> > 
> > My application is a native Windows app (64 and 32-bit).  It includes
> > no cygwin libraries and is not compiled with cygwin's gcc.  When I
> > execute cygwin programs from my app, however, the return value
> > obtained from cygwin programs is always 0.
> > 
> > More precisely, I spawn a particular cygwin program, say `make' or
> > `sh', with CreateProcess().  When the program exits
> > GetExitCodeProcess() always sets the exit status to 0, no matter what
> > the real exit status was.
> 
> I just applied a patch which should return the correct error code.

Ah, yes, I forgot:  Please test the next snapshot from
http://cygwin.com/snapshots/


Corinna

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: problems with exit codes on 64-bit Windows XP Pro x64

[Kevin Layer]

Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

>> > I just applied a patch which should return the correct error code.
>> 
>> Ah, yes, I forgot:  Please test the next snapshot from
>> http://cygwin.com/snapshots/

The problem is fixed.  Thank you very much, Corinna.

I'd like to second William's comments: cygwin and the cygwin
development team rock!

Kevin

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: problems with exit codes on 64-bit Windows XP Pro x64

[Christopher Faylor]

On Thu, Feb 09, 2006 at 12:32:56PM -0800, Kevin Layer wrote:
>Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
>
>>> > I just applied a patch which should return the correct error code.
>>> 
>>> Ah, yes, I forgot:  Please test the next snapshot from
>>> http://cygwin.com/snapshots/
>
>The problem is fixed.  Thank you very much, Corinna.
>
>I'd like to second William's comments: cygwin and the cygwin
>development team rock!

In that case, I claim total credit, since I generated the snapshot.

Corinna just did the trivial step of checking in the fix.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: problems with exit codes on 64-bit Windows XP Pro x64

[Kevin Layer]

Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:

>> On Feb  6 14:49, Kevin Layer wrote:
>> > I'm running the latest cygwin (1.5.19, see cygcheck below).
>> > 
>> > My application is a native Windows app (64 and 32-bit).  It includes
>> > no cygwin libraries and is not compiled with cygwin's gcc.  When I
>> > execute cygwin programs from my app, however, the return value
>> > obtained from cygwin programs is always 0.
>> > 
>> > More precisely, I spawn a particular cygwin program, say `make' or
>> > `sh', with CreateProcess().  When the program exits
>> > GetExitCodeProcess() always sets the exit status to 0, no matter what
>> > the real exit status was.
>> 
>> I just applied a patch which should return the correct error code.

Thanks!

>> Thanks for the testcase, it's highly appreciated, though... it was
>> a lot of code for emulating cmd's "echo %errorlevel%" ;-)

Yeah.  Originally, we thought it was a Microsoft bug... so we went the
extra mile.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP SP2

[Jeff.Hodges]

Jeff.Hodges@KingsMountain.com said:
> If this were to come to pass and  not be addressed by the cygwin
> community, then it wouldn't make any sense to  have the the default
> (or even option) of creating cygwin symlinks as  "winsymlinks".

oops. add "...on XP and possibly derivatives thereof."

JeffH



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP SP2

[Jeff.Hodges]

skoehler@upb.de said:
> He clearly complained about MS-Software that  cannot handle
> cygwin-created links, and you're talking about cygwin  understand its
> own symlinks

correct. thanks.


cgf-no-personal-reply-please@cygwin.com said:
> Apologies.  I took the word "altogether" to mean "completely" but
> obviously missed the meaning implied by "from the windoze
> perspective".

accepted & understood. thanks.


So, again, from the perspective of having cygwin-created symlinks that 
transparently behave as windows shortcuts, they (cygwin-created symlinks) are 
presently half-broken on XP.  And if MSFT were to for some reason align their 
explorer code to match their Open-Save dialog code wrt how they treat (and 
discriminate between) shortcuts, cygwin-created symlink/shortcuts would likely 
quit working entirely *in the windows world* (they'd of course likely to 
continue to work fine in the cygwin world). If this were to come to pass and 
not be addressed by the cygwin community, then it wouldn't make any sense to 
have the the default (or even option) of creating cygwin symlinks as 
"winsymlinks". This would be a loose, imv.

thanks,

JeffH



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

odd behavior of symlinks on Win XP SP2

[Jeff.Hodges]

I've searched this list and googled and all, and can't find anything about 
this issue, so perhaps it's some cockpit error on my part. Anyways, here's the 
issue/question...

  cygwin symlinks (aka cygwin-created windows shortcuts) seem to work 
  differently, and incorrectly, from the windows perspective, on Win XP SP2
  than they did on (say) Win 2000 Pro. 

On Win2k, I got into the habit of creating many of my symlinks/shortcuts via 
Cygwin ("ln -s" of course) because then they were available, and worked 
correctly, from both the Cygwin and windows perspectives.

Mostly these are symlinks to directories which I use to more conveniently 
traipse around my filesystem. This was true of all my cygwin install/upgrades 
on Win2k from say 1999 thru 2004. The native Win filesystem has been NTFS in 
all cases, fwiw.

However, now on Win XP SP2 (professional) -- I moved to XP SP2 from Win2k in 
Nov-2004 -- I notice the following behavior with both existing 
symlinks/shortcuts copied over to XP from my Win2k box and with new symlinks 
I've created with my newly-upgraded (27-Dec-2004) cygwin install (on XP)...

1. cygwin-created (via "ln -s") symlinks/shortcuts pointing to a directory are 
displayed in windows file dialogs with the windows default "funky file" icon 
(I dunno what it's actual name is) rather than the windows folder icon as used 
to be the case on win2k/cygwin.

2. cygwin-created (via "ln -s") symlinks/shortcuts pointing to a directory are 
displayed in some windows file-open or file-save dialogs, but not in others. 
On win2k/cygwin, they were always displayed and always behaved exactly like 
windows-created shortcuts pointing to a directory. In terms of how they are 
behaving on WinXP/cygwin..

2.1. In the cases where they *are* displayed in windows file-open or file-save 
dialogs, e.g. using windows version of OpenOffice 1.1.3, the program in 
question attempts to either open the symlink/shortcut file itself or overwrite 
it, respectively.

2.2. In the cases where they "are not* displayed in the windows dialog 
(whether open or save), e.g. as done by Firefox 1.0 in the file-save case, 
well, the symlink/shortcut simply isn't listed in the dialog, when on 
win2k/cygwin they were displayed (and behaved) just fine.


I suspect either there's some cockpit error I've committed (or am committing) 
either or both on the Win XP side or the Cygwin side, OR, there's something 
different with Win XP SP2 wrt shortcuts that's causing this.

I do have a symlink or two that I'd created on win2k/cygwin that I copied over 
to the WinXP/cygwin machine (as a part of a  copied-over filesystem subtree) 
that behaves (on XP) as it did on win2k. Yet there are other 
symlinks/shortcuts in the same filesystem subtree that now work incorrectly.

Has anyone else noticed this behavior? If so do you have any ideas on how to 
get it rectified?

thanks,

JeffH





--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP SP2

[Igor Pechtchanski]

On Fri, 14 Jan 2005, Jeff.Hodges wrote:

> I've searched this list and googled and all, and can't find anything
> about this issue, so perhaps it's some cockpit error on my part.
> Anyways, here's the issue/question...
>
>   cygwin symlinks (aka cygwin-created windows shortcuts) seem to work
>   differently, and incorrectly, from the windows perspective, on Win XP
>   SP2 than they did on (say) Win 2000 Pro.
>
> On Win2k, I got into the habit of creating many of my symlinks/shortcuts
> via Cygwin ("ln -s" of course) because then they were available, and
> worked correctly, from both the Cygwin and windows perspectives.
>
> Mostly these are symlinks to directories which I use to more
> conveniently traipse around my filesystem. This was true of all my
> cygwin install/upgrades on Win2k from say 1999 thru 2004. The native Win
> filesystem has been NTFS in all cases, fwiw.
>
> However, now on Win XP SP2 (professional) -- I moved to XP SP2 from
> Win2k in Nov-2004 -- I notice the following behavior with both existing
> symlinks/shortcuts copied over to XP from my Win2k box and with new
> symlinks I've created with my newly-upgraded (27-Dec-2004) cygwin
> install (on XP)...
>
> 1. cygwin-created (via "ln -s") symlinks/shortcuts pointing to a
> directory are displayed in windows file dialogs with the windows default
> "funky file" icon (I dunno what it's actual name is) rather than the
> windows folder icon as used to be the case on win2k/cygwin.
>
> 2. cygwin-created (via "ln -s") symlinks/shortcuts pointing to a
> directory are displayed in some windows file-open or file-save dialogs,
> but not in others. On win2k/cygwin, they were always displayed and
> always behaved exactly like windows-created shortcuts pointing to a
> directory. In terms of how they are behaving on WinXP/cygwin..
>
> 2.1. In the cases where they *are* displayed in windows file-open or
> file-save dialogs, e.g. using windows version of OpenOffice 1.1.3, the
> program in question attempts to either open the symlink/shortcut file
> itself or overwrite it, respectively.
>
> 2.2. In the cases where they "are not* displayed in the windows dialog
> (whether open or save), e.g. as done by Firefox 1.0 in the file-save
> case, well, the symlink/shortcut simply isn't listed in the dialog, when
> on win2k/cygwin they were displayed (and behaved) just fine.

Hmm, interesting.  I've never noticed this, but your mail prompted me to
look on my own machine.  And, lo and behold, on a plain WinXP SP1 (note,
no SP2) I get the same behavior.

> I suspect either there's some cockpit error I've committed (or am
> committing) either or both on the Win XP side or the Cygwin side, OR,
> there's something different with Win XP SP2 wrt shortcuts that's causing
> this.

I'd say the latter (except it applies to WinXP in general, not just SP2).

> I do have a symlink or two that I'd created on win2k/cygwin that I
> copied over to the WinXP/cygwin machine (as a part of a copied-over
> filesystem subtree) that behaves (on XP) as it did on win2k. Yet there
> are other symlinks/shortcuts in the same filesystem subtree that now
> work incorrectly.
>
> Has anyone else noticed this behavior? If so do you have any ideas on
> how to get it rectified?

I've noticed this.  Further, after a quick look at the structure of the
symlinks[*] shows that the shortcuts created by WinXP have much more stuff
in them (513 bytes vs. 115 bytes), and they seem to have most of the stuff
(comments and paths) in Unicode.  I suspect that WinXP doesn't really deal
well with non-Unicode shortcuts.

Perhaps an update to Cygwin's symlink() implementation is in order?  The
one that's there now actually has the structure of a Windows symlink
hard-coded in (which apparently fails on XP).  See path.cc in
src/winsup/cygwin.  <http://cygwin.com/acronyms/#PTC>.
HTH,
	Igor
[*] BTW, if you have a symlink named "foo", run "attrib -R foo.lnk" to be
able to view (and maybe even edit, if you know what you're doing) the
contents in vi, and then "attrib +R foo.lnk" to turn it back to a symlink.
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: odd behavior of symlinks on Win XP SP2

[Corinna Vinschen]

On Jan 14 20:05, Igor Pechtchanski wrote:
> On Fri, 14 Jan 2005, Jeff.Hodges wrote:
> > Mostly these are symlinks to directories which I use to more
> > conveniently traipse around my filesystem. This was true of all my
> > cygwin install/upgrades on Win2k from say 1999 thru 2004. The native Win
> > filesystem has been NTFS in all cases, fwiw.

2001.  The shortcuts have been added to Cygwin in 2001.

> > 1. cygwin-created (via "ln -s") symlinks/shortcuts pointing to a
> > directory are displayed in windows file dialogs with the windows default
> > "funky file" icon (I dunno what it's actual name is) rather than the
> > windows folder icon as used to be the case on win2k/cygwin.
> > 
> > 2. cygwin-created (via "ln -s") symlinks/shortcuts pointing to a
> > directory are displayed in some windows file-open or file-save dialogs,
> > but not in others. On win2k/cygwin, they were always displayed and
> > always behaved exactly like windows-created shortcuts pointing to a
> > directory. In terms of how they are behaving on WinXP/cygwin..
> >
> > 2.1. In the cases where they *are* displayed in windows file-open or
> > file-save dialogs, e.g. using windows version of OpenOffice 1.1.3, the
> > program in question attempts to either open the symlink/shortcut file
> > itself or overwrite it, respectively.
> >
> > 2.2. In the cases where they "are not* displayed in the windows dialog
> > (whether open or save), e.g. as done by Firefox 1.0 in the file-save
> > case, well, the symlink/shortcut simply isn't listed in the dialog, when
> > on win2k/cygwin they were displayed (and behaved) just fine.
> 
> Hmm, interesting.  I've never noticed this, but your mail prompted me to
> look on my own machine.  And, lo and behold, on a plain WinXP SP1 (note,
> no SP2) I get the same behavior.

But they work in Windows Explorer, nevertheless.  We're not in control
of the icon used by Windows.  As soon as we do, the shortcut is not a
Cygwin shortcut anymore and it's saved by tar as a file rather than a
symlink.

> I've noticed this.  Further, after a quick look at the structure of the
> symlinks[*] shows that the shortcuts created by WinXP have much more stuff
> in them (513 bytes vs. 115 bytes), and they seem to have most of the stuff
> (comments and paths) in Unicode.  I suspect that WinXP doesn't really deal
> well with non-Unicode shortcuts.
> 
> Perhaps an update to Cygwin's symlink() implementation is in order?  The
> one that's there now actually has the structure of a Windows symlink
> hard-coded in (which apparently fails on XP).  See path.cc in
> src/winsup/cygwin.  <http://cygwin.com/acronyms/#PTC>.

It has been done so for speed.  And it doesn't really fail.  The shortcut
is still a shortcut in Windows Explorer.  I'm wondering if it's really 
the Unicodeness of the shortcut which makes the difference.  Usually
shortcuts generated in Windows Explorer are much longer anyway.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: emacs 100% cpu usage bug

[Christopher Faylor]

Please check out the project web page for links to available information
and ports:  http://cygwin.com/ .

If you don't see what you need there, then the cygwin mailing list is
the best place to make observations or get questions answered.
Information on the mailing list is available at the project web page.

For your convenience, I've reset the Reply-To: address to point to the
cygwin mailing list.  I've also Cc'ed this reply there.

On Wed, Nov 20, 2002 at 07:06:56PM -0500, Zdzislaw Meglicki wrote:
>Dear Christopher,
>
>I have downloaded and installed the latest, I presume, version of Cygwin,
>with some additional updates downloaded only today from a NASA Cygwin
>mirror, and... I am still plagued by the "emacs 100% CPU usage bug", i.e.,
>when emacs is invoked in the X11 environment, it spins and doesn't come up.
>When it is invoked in a no-X11 environment, it works fine.
>
>I have perused the mailing lists, both cygwin-xfree and cygwin, and found
>that "the latest snapshot", I guess of cygwin1.dll, fixes the problem. So my
>question is how I can download this latest snapshot. I haven't seen it on
>Cygwin mirrors at the ANL and NASA. But they seem to have various other
>fixes, e.g., for gcc.
>
>Best regards,

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: emacs 100% cpu usage bug

[Jim Goltz]

Zdzislaw Meglicki writes:

zm> I have downloaded and installed the latest, I presume, version of
zm> Cygwin, with some additional updates downloaded only today from a
zm> NASA Cygwin mirror, and... I am still plagued by the "emacs 100%
zm> CPU usage bug", i.e., when emacs is invoked in the X11
zm> environment, it spins and doesn't come up. When it is invoked in a
zm> no-X11 environment, it works fine.

I'm having the same problem. I'm running Cygwin 1.3.15-2 (the latest
as of this date). "emacs -nw" from a cygwin shell works fine, although
control characters are mapped oddly (ctrl-H is backward-delete-char-
untabify, ctrl-C is keyboard-quit, etc.). "emacs" attempts to start
the X version of Emacs, which grabs 100% of the CPU time and locks the
system, regardless of whether an X server is running. Other X apps
(local and remote) work just fine.

This started happening after an upgrade about a week ago.

Anyone have any ideas?

--
James P. Goltz <goltz@mmert.org>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: emacs 100% cpu usage bug

[Igor Pechtchanski]

On 21 Nov 2002, Jim Goltz wrote:

> Zdzislaw Meglicki writes:
>
> zm> I have downloaded and installed the latest, I presume, version of
> zm> Cygwin, with some additional updates downloaded only today from a
> zm> NASA Cygwin mirror, and... I am still plagued by the "emacs 100%
> zm> CPU usage bug", i.e., when emacs is invoked in the X11
> zm> environment, it spins and doesn't come up. When it is invoked in a
> zm> no-X11 environment, it works fine.
>
> I'm having the same problem. I'm running Cygwin 1.3.15-2 (the latest
> as of this date). "emacs -nw" from a cygwin shell works fine, although
> control characters are mapped oddly (ctrl-H is backward-delete-char-
> untabify, ctrl-C is keyboard-quit, etc.). "emacs" attempts to start
> the X version of Emacs, which grabs 100% of the CPU time and locks the
> system, regardless of whether an X server is running. Other X apps
> (local and remote) work just fine.
>
> This started happening after an upgrade about a week ago.
>
> Anyone have any ideas?

I think the point of the message you quoted was in the part that you left
out.  It said "try the latest snapshot".  See http://cygwin.com/ for
details (if you don't find it at first glance, just search that page for
"snapshot").
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Water molecules expand as they grow warmer" (C) Popular Science, Oct'02, p.51


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: emacs 100% cpu usage bug

[Jim Goltz]

Igor Pechtchanski writes:

ip> I think the point of the message you quoted was in the part that
ip> you left out. It said "try the latest snapshot".

The point of my message was, I *am* running the latest snapshot.

--
James P. Goltz <goltz@mmert.org>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: emacs 100% cpu usage bug

[Christopher Faylor]

On Sat, Nov 23, 2002 at 03:22:24PM -0500, Jim Goltz wrote:
>Igor Pechtchanski writes:
>
>ip> I think the point of the message you quoted was in the part that
>ip> you left out. It said "try the latest snapshot".
>
>The point of my message was, I *am* running the latest snapshot.

Your message said that you were running 1.3.15-2.  That is not the
latest snapshot.

Go to the cygwin web page and look for the word "snapshot".  Click on
the appropriate link and you'll see how to download a snapshot.

FYI, a release is not a snapshot.

cgf
--
Please do not send me personal email with cygwin questions or observations.
Use the resources at http://cygwin.com/ .

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: emacs 100% cpu usage bug

[Jim Goltz]

Christopher Faylor writes:

cf> FYI, a release is not a snapshot.

Mea culpa.

--
James P. Goltz <goltz@mmert.org>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/