Setup 2.712 crashes when running reinstall after install

[KJ]

Hi all,

the setup.exe crashes when I do are install after an install operation
(downloading files only). When I click back after installation complete
to select reinstall the a message box appears with "Download incomplete.
Try again?". If I select yes then then download site list appears. After
selecting next the select packages window appears having set reinstall
in the All Category (others default). Selecting next again crashes
setup.exe.

OS is Win7 64-bit.

This used to work up the previous version of setup.exe

KJ

PS: the crash also happens when running reinstall from the very beginning.

Problemsignatur:
  Problemereignisname:  APPCRASH
  Anwendungsname:   setup.exe_unknown
  Anwendungsversion:0.0.0.0
  Anwendungszeitstempel:4c617e25
  Fehlermodulname:  StackHash_0a9e
  Fehlermodulversion:   0.0.0.0
  Fehlermodulzeitstempel:   
  Ausnahmecode: c005
  Ausnahmeoffset:   009a9d58
  Betriebsystemversion: 6.1.7600.2.0.0.256.4
  Gebietsschema-ID: 1031
  Zusatzinformation 1:  0a9e
  Zusatzinformation 2:  0a9e372d3b4ad19135b953a78882e789
  Zusatzinformation 3:  0a9e
  Zusatzinformation 4:  0a9e372d3b4ad19135b953a78882e789

Lesen Sie unsere Datenschutzbestimmungen online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie
unsere Datenschutzbestimmungen offline:
  C:\Windows\system32\de-DE\erofflps.txt

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

Re: Postinstall for mintty fails when installing "just for me"

[Corinna Vinschen]

On Aug 17 15:12, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:49 AM
> >> On 17 August 2010 02:26, Buchbinder, Barry wrote:
> >> > $ bash --norc --noprofile /etc/postinstall/mintty.sh
> >> > /bin/mkdir: cannot create directory `/c/Documents and Settings/All
> >> > Users/Start Menu/Programs/Cygwin': Permission denied
> >> > mkshortcut: Saving "C:\Documents and Settings\All Users\Start 
> >> > Menu\Programs\Cygwin\mintty.lnk" failed; does the target directory exist?
> >> > /bin/chmod: cannot access `/c/Documents and Settings/All Users/Start
> >> > Menu/Programs/Cygwin/mintty.lnk': No such file or directory echo $?
> >> > 1
> >[...]
> >The problem is, we don't know anything about your environment, Barry.
> >cygcheck output as requested by http://cygwin.com/problems.html would be
> >helpful, perhaps.
> 
> Attached.
> 
> Please note:
> 
> $ cygcheck -s -v -r > cygcheck.out
> /usr/bin/cygrunsrv: warning: OpenService failed for 'TapiSrv': Win32 error 5
> Access is denied.

That usually just means you don't have admin privs.

> 
> >As is getfacl/cacls output for the "/c/Documents and
> >Settings/All Users/Start Menu/Programs" directory.
> 
> $ getfacl '/c/Documents and Settings/All Users/Start Menu/Programs'
> # file: /c/Documents and Settings/All Users/Start Menu/Programs
> # owner: BBuchbinder
> # group: Domain Users
> user::rwx
> group::r-x
> other:r-x
> mask:rwx
> 
> $ cacls 'C:\Documents and Settings\All Users\Start Menu\Programs'
> C:\Documents and Settings\All Users\Start Menu\Programs 
> BUILTIN\Administrators:(OI)(CI)F
> CREATOR 
> OWNER:(OI)(CI)(IO)F
> NT 
> AUTHORITY\SYSTEM:(OI)(CI)F
> 
> BUILTIN\Users:(OI)(CI)R
>[...]

Here's the actual problem:

  cygdrive prefix / system  binary,noacl,posix=0,auto

The cygdrive prefix is set to the mount option "noacl".  So the output
from getfacl or ls or stat for this directory shows just fake
permissions based on the DOS R/O flag.

You're not an admin, so you're not allowed to write to this directory,
see the cacls output.  However, since the cygdrive prefix is mounted
with "noacl", Cygwin tools just don't know it.

Andy, to workaround this, you *could* create a user mount first which
has no "noacl", then use the user mount to check permissions, and
eventually umount again.  Like this:

  PROGS=/tmp/.mintty-postinstall-$$
  mount -f "`cygpath -APm`" $PROGS
  if [ -w "$PROGS" ]; then
[...]
  else
[...]
  fi
  umount $PROGS


Corinna

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

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

Re: cygwin 1.7 lock directory problem

[Corinna Vinschen]

On Aug 18 01:52, Christopher Faylor wrote:
> On Wed, Aug 18, 2010 at 01:05:13PM +0800, Huang Bambo wrote:
> >>Do you have a series of steps that produces the problem you see?
> >>
> >
> >As I said in previous mail.
> >1. cd /cygdriver/i( I is mounted as a usb-stick)
> >2.  cd /proc 3.  Use some tools such as Unlocker to check driver I,
> >Unlocker said driver I is locked by bash.
> >4. cd /  ( / is at d:\cygwin )
> >5.  do the same as step 3, driver is not locked by bash.
> 
> That's how Cygwin 1.7.5 would work.  I would expect different behavior
> for 1.7.6.

No, that's also how 1.7.6 works.  I documented this behaviour in
path.cc:

  /* Note that we don't set the dir handle to NULL for virtual paths.
 The handle is used to generate a stackdump file.  Since we can't
 create a stackdump in a virtual path, we have at least *some*
 directory handle to generate the stackdump in.

 However, note that we have to make sure that we don't use the handle
 wrongly as soon as we start to use it in other cases as well. */

Looks like this behaviour is a problem and we should better close the
old handle.  What to do with the new one?  Just set it to NULL and
disallow stackdumps as long as we're in a virtual path?  Or set it to
some well known path, like Cygwin's root?


Corinna

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

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

Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff

[Corinna Vinschen]

On Aug 17 22:44, Pedro Izecksohn wrote:
> --- Corinna Vinschen wrote:
> >
> > For this patch, given that it is just a bunch of rather obvious
> > defines, I don't think we have to treat the patch as significant.
> 
>   I do not think that these macros are obvious. I think that I was
> there when these macros were first implemented at 1987: I talked with
> the programmer who was paid by the Correios to port everything from
> the mainframe to the Apple II. I was a stenchy kid with his father,
> that asked the employee what he was doing. When I asked about other
> possibilities of endianness, the programmer answered about the PDP.
> The programmer explained about BSD being a flavor of Unix. That talk
> changed my life.
> 
> > However, please don't use _BSD_SOURCE.  The newlib/Cygwin headers are
> > not set up like the Linux headers and the big bunch of definitions from
> > /usr/include/features.h are not available so far.  The _BSD_SOURCE
> > define is not honored or set anywhere right now.
> >
> > What you can do is to use _POSIX_SOURCE.  So, if you're going to use
> > #ifndef _POSIX_SOURCE instead, and if you're creating a ChangeLog entry
> > in the correct ChangeLog entry format (see the ChangeLog file), then
> > I guess we can check it in.
> 
>   Would you agree with:
> 
> #if defined _BSD_SOURCE || ! defined _POSIX_SOURCE

Ok.


Corinna

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

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

Re: mknod bug? major minor's are whacky

[Corinna Vinschen]

On Aug 17 17:51, Eric Blake wrote:
> On 08/17/2010 05:46 PM, Bob Goldberg wrote:
> > cygwin 1.7.6
> > 
> > attempting to:
> > $ mknod null c 1 3
> > 
> > what I get is:
> > crw-rw-rw- 1 user mkgroup-l-d 46200, 14467 2010-08-17 18:44 null
> > 
> > WHERE did those crazy major/minor's come from!?!?

They come from Cygwin.  They are an accidental reflection of the
volume id, which is used in stat::st_rdev for files by default.
Cygwin only set st_dev to the device number so far.  I fixed that
in CVS so that st_rdev and st_dev both contain the device number
now for device files.


Thanks for the report,
Corinna

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

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

Re: cygwin 1.7 lock directory problem

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >>Do you have a series of steps that produces the problem you see?
>> >>
>> >
>> >As I said in previous mail.
>> >1. cd /cygdriver/i( I is mounted as a usb-stick)
>> >2.  cd /proc 3.  Use some tools such as Unlocker to check driver I,
>> >Unlocker said driver I is locked by bash.
>> >4. cd /  ( / is at d:\cygwin )
>> >5.  do the same as step 3, driver is not locked by bash.
>> 
>> That's how Cygwin 1.7.5 would work.  I would expect different behavior
>> for 1.7.6.

> No, that's also how 1.7.6 works.  I documented this behaviour in
> path.cc:

>   /* Note that we don't set the dir handle to NULL for virtual paths.
>  The handle is used to generate a stackdump file.  Since we can't
>  create a stackdump in a virtual path, we have at least *some*
>  directory handle to generate the stackdump in.

>  However, note that we have to make sure that we don't use the handle
>  wrongly as soon as we start to use it in other cases as well. */

> Looks like this behaviour is a problem and we should better close the
> old handle.  What to do with the new one?  Just set it to NULL and
> disallow stackdumps as long as we're in a virtual path?  Or set it to
> some well known path, like Cygwin's root?

/var or /tmp would be more sensible.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 18.08.2010, <14:27>

Sorry for my terrible english...


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

Re: cygwin 1.7 lock directory problem

[Corinna Vinschen]

On Aug 18 14:28, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> >>Do you have a series of steps that produces the problem you see?
> >> >>
> >> >
> >> >As I said in previous mail.
> >> >1. cd /cygdriver/i( I is mounted as a usb-stick)
> >> >2.  cd /proc 3.  Use some tools such as Unlocker to check driver I,
> >> >Unlocker said driver I is locked by bash.
> >> >4. cd /  ( / is at d:\cygwin )
> >> >5.  do the same as step 3, driver is not locked by bash.
> >> 
> >> That's how Cygwin 1.7.5 would work.  I would expect different behavior
> >> for 1.7.6.
> 
> > No, that's also how 1.7.6 works.  I documented this behaviour in
> > path.cc:
> 
> >   /* Note that we don't set the dir handle to NULL for virtual paths.
> >  The handle is used to generate a stackdump file.  Since we can't
> >  create a stackdump in a virtual path, we have at least *some*
> >  directory handle to generate the stackdump in.
> 
> >  However, note that we have to make sure that we don't use the handle
> >  wrongly as soon as we start to use it in other cases as well. */
> 
> > Looks like this behaviour is a problem and we should better close the
> > old handle.  What to do with the new one?  Just set it to NULL and
> > disallow stackdumps as long as we're in a virtual path?  Or set it to
> > some well known path, like Cygwin's root?
> 
> /var or /tmp would be more sensible.

Maybe, but it also costs time.  /var and /tmp Windows paths have to be
generated by a full path conversion every time you call chdir() to a
virtual directory.
The Cygwin installation path (aka the root dir) is just available.


Corinna

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

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

Re: mintty hangs after SSH disconnect

[Andy Koppe]

On 18 August 2010 09:51, Csaba Raduly wrote:
> The following scenario keeps happening more often than I like:
>
> I open a mintty console with a ssh:
> C:\cygwin17\bin\mintty.exe /bin/bash --login -c "/usr/bin/ssh -Y lablinux1"
>
> (time passes)
> I set the computer to sleep (the power button is reconfigured to sleep
> instead of shutdown).
>
> When I come back (usually the next day) and bring the computer back
> up, the SSH connection is lost:
> "Write error: connection reset by peer"
>
> This is understandable, considering the long time gap with no connection.
> The normal behavior is that after pressing Enter, the mintty window 
> disappears.
>
> However, sometimes at this point mintty is consuming 100% CPU and has
> to be killed manually.

That's http://code.google.com/p/mintty/issues/detail?id=211, broken
since 0.8-beta1, reported and fixed in svn for 0.8.2 just last night.

Btw, the close button and Alt+F4 should still work inspite of the 100%
CPU. I guess I better also restore the behaviour where any keypress
closes the terminal if the pty has reported EOF.

Andy

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

Re: Postinstall for mintty fails when installing "just for me"

[Andy Koppe]

On 18 August 2010 09:43, Corinna Vinschen wrote:
> On Aug 17 15:12, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>> Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:49 AM
>> >> On 17 August 2010 02:26, Buchbinder, Barry wrote:
>> >> > $ bash --norc --noprofile /etc/postinstall/mintty.sh
>> >> > /bin/mkdir: cannot create directory `/c/Documents and Settings/All
>> >> > Users/Start Menu/Programs/Cygwin': Permission denied
>> >> > mkshortcut: Saving "C:\Documents and Settings\All Users\Start 
>> >> > Menu\Programs\Cygwin\mintty.lnk" failed; does the target directory 
>> >> > exist?
>> >> > /bin/chmod: cannot access `/c/Documents and Settings/All Users/Start
>> >> > Menu/Programs/Cygwin/mintty.lnk': No such file or directory echo $?
>> >> > 1
>> >[...]
>> >The problem is, we don't know anything about your environment, Barry.
>> >cygcheck output as requested by http://cygwin.com/problems.html would be
>> >helpful, perhaps.
>>
>> Attached.
>>
>> Please note:
>>
>> $ cygcheck -s -v -r > cygcheck.out
>> /usr/bin/cygrunsrv: warning: OpenService failed for 'TapiSrv': Win32 error 5
>> Access is denied.
>
> That usually just means you don't have admin privs.
>
>>
>> >As is getfacl/cacls output for the "/c/Documents and
>> >Settings/All Users/Start Menu/Programs" directory.
>>
>> $ getfacl '/c/Documents and Settings/All Users/Start Menu/Programs'
>> # file: /c/Documents and Settings/All Users/Start Menu/Programs
>> # owner: BBuchbinder
>> # group: Domain Users
>> user::rwx
>> group::r-x
>> other:r-x
>> mask:rwx
>>
>> $ cacls 'C:\Documents and Settings\All Users\Start Menu\Programs'
>> C:\Documents and Settings\All Users\Start Menu\Programs 
>> BUILTIN\Administrators:(OI)(CI)F
>>                                                         CREATOR 
>> OWNER:(OI)(CI)(IO)F
>>                                                         NT 
>> AUTHORITY\SYSTEM:(OI)(CI)F
>>                                                         
>> BUILTIN\Users:(OI)(CI)R
>>[...]
>
> Here's the actual problem:
>
>  cygdrive prefix     /         system  binary,noacl,posix=0,auto
>
> The cygdrive prefix is set to the mount option "noacl".  So the output
> from getfacl or ls or stat for this directory shows just fake
> permissions based on the DOS R/O flag.

Thanks very much for spotting that.


> You're not an admin, so you're not allowed to write to this directory,
> see the cacls output.  However, since the cygdrive prefix is mounted
> with "noacl", Cygwin tools just don't know it.
>
> Andy, to workaround this, you *could* create a user mount first which
> has no "noacl", then use the user mount to check permissions, and
> eventually umount again.  Like this:
>
>  PROGS=/tmp/.mintty-postinstall-$$
>  mount -f "`cygpath -APm`" $PROGS
>  if [ -w "$PROGS" ]; then
>    [...]
>  else
>    [...]
>  fi
>  umount $PROGS

Hmm, I'm a bit afraid that might find creative new ways of going wrong. ;)

I think I'll go with your previous suggestion of just going ahead and
trying to create the 'All Users' shortcut and falling back to the
user's start menu if that fails.

Although, perhaps there's a way to tell from $CYGWINROOT whether we're
dealing with an install for all users or "just me"?

Andy

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

Re: Postinstall for mintty fails when installing "just for me"

[Corinna Vinschen]

On Aug 18 12:24, Andy Koppe wrote:
> On 18 August 2010 09:43, Corinna Vinschen wrote:
> > Andy, to workaround this, you *could* create a user mount first which
> > has no "noacl", then use the user mount to check permissions, and
> > eventually umount again.  Like this:
> >
> >  PROGS=/tmp/.mintty-postinstall-$$
> >  mount -f "`cygpath -APm`" $PROGS
> >  if [ -w "$PROGS" ]; then
> >    [...]
> >  else
> >    [...]
> >  fi
> >  umount $PROGS
> 
> Hmm, I'm a bit afraid that might find creative new ways of going wrong. ;)

The only way that could go wrong is, if the user already has 30 mount
points, since that's the current maximum nuber of allowed mounts.

> I think I'll go with your previous suggestion of just going ahead and
> trying to create the 'All Users' shortcut and falling back to the
> user's start menu if that fails.
> 
> Although, perhaps there's a way to tell from $CYGWINROOT whether we're
> dealing with an install for all users or "just me"?

No, but I don't think it would hurt to enhance setup.exe, either by
adding arguments to postinstall/preremove scripts, or by adding an
environment variable like $CYGWIN_AUDIENCE with the values "all_user" or
"just_me".


Corinna

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

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

[ANNOUNCEMENT] Updated [experimental]: {emacs,emacs-X11,emacs-el}-23.2-2

[Ken Brown]

New releases of the emacs, emacs-X11, and emacs-el packages (23.2-2) are 
now available as experimental packages.  These are rebuilds of the 
23.2-1 packages, with D-BUS support.  You will need to install 
libdbus1_3 in order to run the new binaries.  Please report any 
regressions.  If nothing serious is reported, the new releases will be 
promoted to "current" in a few weeks.


CYGWIN NOTES

There is a known bug in the cygwin build of emacs, which affects emacs 
functions like display-time.  See /usr/share/doc/Cygwin/emacs.README for 
details and a simple workaround.


Install the emacs-X11 package if you want to use the X11 GUI.  You can 
then type 'emacs&' in an xterm window, and emacs will start in a new window.


If you run emacs in the cygwin console, be sure that your CYGWIN 
environment variable (http://cygwin.com/cygwin-ug-net/setup-env.html) 
contains tty.


The script /usr/bin/make-emacs-shortcut can be used to create a shortcut 
for starting emacs.  The shortcut starts emacs under X if an X server is 
running and in a mintty window otherwise.  Edit the shortcut and/or the 
script if you want different behavior.


You will need the cygutils package to run the script, and you will need 
mintty and run2 to use the shortcut.  In addition, the user who runs the 
script needs to be able to write to /usr/local/bin.


EMACS NEWS
==
See http://www.gnu.org/software/emacs/ for a summary of new features 
since Emacs 23.1.  You can also use the command 'C-h n' within emacs to 
browse the NEWS file.


DESCRIPTION
===
Emacs is a powerful, customizable, self-documenting, modeless text 
editor.  Emacs contains special code editing features, a scripting 
language (elisp), and the capability to read mail, news, and more 
without leaving the editor.


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


Ken Brown
Cygwin emacs maintainer

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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


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

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

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

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





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

Re: Postinstall for mintty fails when installing "just for me"

[Corinna Vinschen]

On Aug 18 13:35, Corinna Vinschen wrote:
> On Aug 18 12:24, Andy Koppe wrote:
> > On 18 August 2010 09:43, Corinna Vinschen wrote:
> > > Andy, to workaround this, you *could* create a user mount first which
> > > has no "noacl", then use the user mount to check permissions, and
> > > eventually umount again.  Like this:
> > >
> > >  PROGS=/tmp/.mintty-postinstall-$$
> > >  mount -f "`cygpath -APm`" $PROGS
> > >  if [ -w "$PROGS" ]; then
> > >    [...]
> > >  else
> > >    [...]
> > >  fi
> > >  umount $PROGS
> > 
> > Hmm, I'm a bit afraid that might find creative new ways of going wrong. ;)
> 
> The only way that could go wrong is, if the user already has 30 mount
> points, since that's the current maximum nuber of allowed mounts.

Btw., see /bin/ssh-host-config, line 93 :)


Corinna

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

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

Re: Cygwin 1.7.5 segfault during setup

[Steve Marotta]

I'm still having this error. Is it possible for the Cygwin folks to
create a setup.exe that includes debugging symbols so I can get more
information out of gdb? It's a long shot, I know, but it's worth a
try.

On Mon, Aug 16, 2010 at 5:32 PM, Steve Marotta  wrote:
> I am using Cygwin 1.7.5, upgraded from 1.5, or so I think. I am trying
> to run setup.exe so I can install new packages. I select "Install from
> Internet" and "Direct Connection", and my network connection itself
> works fine. When setup tries to download the mirrors list, it says,
> "This application has requested the Runtime to terminate it in an
> unusual way."
>
> I tried running it under gdb, but without debug symbols, it didn't do
> much good. Here's the output:
>
> 
> Starting program: c:/Documents and Settings/smarotta.CRA/My
> Documents/downloads/setup-1.7.5.exe
> Loaded symbols for C:\WINDOWS\system32\ntdll.dll
> Loaded symbols for C:\WINDOWS\system32\kernel32.dll
> Loaded symbols for C:\WINDOWS\system32\advapi32.dll
> Loaded symbols for C:\WINDOWS\system32\rpcrt4.dll
> Loaded symbols for C:\WINDOWS\system32\secur32.dll
> Loaded symbols for
> C:\WINDOWS\WinSxS\X86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll
> Loaded symbols for C:\WINDOWS\system32\msvcrt.dll
> Loaded symbols for C:\WINDOWS\system32\gdi32.dll
> Loaded symbols for C:\WINDOWS\system32\user32.dll
> Loaded symbols for C:\WINDOWS\system32\shlwapi.dll
> Loaded symbols for C:\WINDOWS\system32\ole32.dll
> Loaded symbols for C:\WINDOWS\system32\shell32.dll
> Loaded symbols for C:\WINDOWS\system32\wsock32.dll
> Loaded symbols for C:\WINDOWS\system32\ws2_32.dll
> Loaded symbols for C:\WINDOWS\system32\ws2help.dll
> warning: LOG: 2 Starting cygwin install, version 2.697
> warning: LOG: 2 io_stream_cygfile: fopen(/etc/setup/net-proxy-host)
> failed 2 No such file or directory
> warning: LOG: 2 io_stream_cygfile: fopen(/etc/setup/net-proxy-port)
> failed 2 No such file or directory
> warning: LOG: 2 io_stream_cygfile: fopen(/etc/setup/extrakeys) failed
> 2 No such file or directory
> warning: LOG: 2 io_stream_cygfile:
> fopen(/etc/setup/chooser_window_settings) failed 2 No such file or
> directory
> warning: LOG: 2 Current Directory: C:\Documents and 
> Settings\smarotta\Home\temp
> warning: LOG: 2 User has backup/restore rights
> warning: LOG: 2 Changing gid to Administrators
> warning: LOG: 2 Could not open service McShield for query, start and
> stop. McAfee may not be installed, or we don't have access.
> warning: LOG: 2 source: network install
> warning: LOG: 2 root: C:\cygwin binary system
> warning: LOG: 2 Selected local directory: C:\Documents and
> Settings\smarotta\Home\temp
> warning: LOG: 2 net: Direct
> warning: LOG: 1 Loaded cached mirror list
> warning: LOG: 1 get_url_to_membuf http://cygwin.com/mirrors.lst
> warning: LOG: 1 getUrlToStream http://cygwin.com/mirrors.lst
>
> Program exited with code 03.
> 
>
> Is there a problem with the cached mirrors list? Can I clear that
> cache? Can it be the .NET framework I have installed on my machine? I
> would appreciate any and all ideas anyone has on how to resolve this
> issue, as I need to use Cygwin as soon as possible.
>
> Thanks,
> Steve
>

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

Re: cygwin 1.7 lock directory problem

[Eric Blake]

On 08/18/2010 05:08 AM, Corinna Vinschen wrote:
>>> Looks like this behaviour is a problem and we should better close the
>>> old handle.  What to do with the new one?  Just set it to NULL and
>>> disallow stackdumps as long as we're in a virtual path?  Or set it to
>>> some well known path, like Cygwin's root?
>>
>> /var or /tmp would be more sensible.
> 
> Maybe, but it also costs time.  /var and /tmp Windows paths have to be
> generated by a full path conversion every time you call chdir() to a
> virtual directory.
> The Cygwin installation path (aka the root dir) is just available.

Using / as the fallback during a virtual directory makes sense to me
(there may be other permission problems if / is not writable by the
current user, but a stack dump is a best effort attempt anyways).

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: cygwin 1.7 lock directory problem

[Huang Bambo]

2010/8/18 Eric Blake :
> On 08/18/2010 05:08 AM, Corinna Vinschen wrote:
 Looks like this behaviour is a problem and we should better close the
 old handle.  What to do with the new one?  Just set it to NULL and
 disallow stackdumps as long as we're in a virtual path?  Or set it to
 some well known path, like Cygwin's root?
>>>
>>> /var or /tmp would be more sensible.
>>
>> Maybe, but it also costs time.  /var and /tmp Windows paths have to be
>> generated by a full path conversion every time you call chdir() to a
>> virtual directory.
>> The Cygwin installation path (aka the root dir) is just available.
>
> Using / as the fallback during a virtual directory makes sense to me
> (there may be other permission problems if / is not writable by the
> current user, but a stack dump is a best effort attempt anyways).
>
Even in linux, you can't generate core file in virtual directory also,
so just don't generate core file if you can't write at anywhere.

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

Re: cygwin 1.7 lock directory problem

[Christopher Faylor]

On Wed, Aug 18, 2010 at 09:51:29PM +0800, Huang Bambo wrote:
>2010/8/18 Eric Blake :
>> On 08/18/2010 05:08 AM, Corinna Vinschen wrote:
> Looks like this behaviour is a problem and we should better close the
> old handle. ?What to do with the new one? ?Just set it to NULL and
> disallow stackdumps as long as we're in a virtual path? ?Or set it to
> some well known path, like Cygwin's root?

 /var or /tmp would be more sensible.
>>>
>>> Maybe, but it also costs time. ?/var and /tmp Windows paths have to be
>>> generated by a full path conversion every time you call chdir() to a
>>> virtual directory.
>>> The Cygwin installation path (aka the root dir) is just available.
>>
>> Using / as the fallback during a virtual directory makes sense to me
>> (there may be other permission problems if / is not writable by the
>> current user, but a stack dump is a best effort attempt anyways).
>>
>Even in linux, you can't generate core file in virtual directory also,
>so just don't generate core file if you can't write at anywhere.

Right.  I don't think we need a fallback.  How is this any different
than what happens when you generate a core dump in linux in a read-only
directory?

cgf

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

Re: cygwin 1.7 lock directory problem

[Corinna Vinschen]

On Aug 18 10:07, Christopher Faylor wrote:
> On Wed, Aug 18, 2010 at 09:51:29PM +0800, Huang Bambo wrote:
> >2010/8/18 Eric Blake :
> >> On 08/18/2010 05:08 AM, Corinna Vinschen wrote:
> > Looks like this behaviour is a problem and we should better close the
> > old handle. ?What to do with the new one? ?Just set it to NULL and
> > disallow stackdumps as long as we're in a virtual path? ?Or set it to
> > some well known path, like Cygwin's root?
> 
>  /var or /tmp would be more sensible.
> >>>
> >>> Maybe, but it also costs time. ?/var and /tmp Windows paths have to be
> >>> generated by a full path conversion every time you call chdir() to a
> >>> virtual directory.
> >>> The Cygwin installation path (aka the root dir) is just available.
> >>
> >> Using / as the fallback during a virtual directory makes sense to me
> >> (there may be other permission problems if / is not writable by the
> >> current user, but a stack dump is a best effort attempt anyways).
> >>
> >Even in linux, you can't generate core file in virtual directory also,
> >so just don't generate core file if you can't write at anywhere.
> 
> Right.  I don't think we need a fallback.  How is this any different
> than what happens when you generate a core dump in linux in a read-only
> directory?

I just applied a matching patch.


Corinna

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

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

"run" changes behavior with cygwin-17.6

[Rodrigo Medina]

Hi,
After upgrading to cygwin17.6 the program run changes behavior.
For example:
If I start mintty with the followin .bat

@echo off
C:
chdir \cygwin\bin
run mintty -e '/bin/bash' --login -i
exit

In the mintty window that is started appears the following message:

/bin/find: failed to restore initial working directory: No such file or
directory

rmed...@limon ~
$

---
The message of  /bin/find is due to the "run" program and does not appear
with cygwin17.5
Everything else is OK

Bye
RM



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

Re: "run" changes behavior with cygwin-17.6

[Corinna Vinschen]

On Aug 18 10:21, Rodrigo Medina wrote:
> Hi,
> After upgrading to cygwin17.6 the program run changes behavior.
> For example:
> If I start mintty with the followin .bat
> 
> @echo off
> C:
> chdir \cygwin\bin
> run mintty -e '/bin/bash' --login -i
> exit
> 
> In the mintty window that is started appears the following message:
> 
> /bin/find: failed to restore initial working directory: No such file or
> directory

Looks like the "run" tool now needs a call to 

  CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd));

and then use win32_cwd in the call to CreateProcess.

See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api


Corinna

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

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

X-forwarding very very slow

[Alberto Canestrelli]

Hi,
I have a problem with Cygwin. I am connecting from USA by ssh to the 
Hector supermachine in Edinburgh ( I write "startx" in Cygwin and then I 
use  "ssh -Y  v1aca...@login.hector.ac.uk" ). Everything works fine, the 
only problem is that the forwarding of the windows is very very slow. It 
takes sometimes also up to 5 minutes to open a new window. I am 
debugging a code with Totalview and it is a impossible to work. I am in 
contact with the Hector support and with their computer they tried to 
run Cygwin under windows and connecting by ssh (exactly like I am doing) 
and they say that x-forwarding  is fast. My version is:


CYGWIN_NT-5.1 1.7.1(0.218/5/3) 2009-12-07 11:48

while their version is:

CYGWIN_NT-6.0 1.5.25(0.156/4/2) 2008-06-12 19:34

So my version is more recent. I do not fell like to downgrade Cygwin,  
everything works well save the slow X-forwarding. Any suggestion please?


Thank you very much
best regards
Alberto

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

Re: X-forwarding very very slow

[Daniel Colascione]

On 8/18/10 8:43 AM, Alberto Canestrelli wrote:
> I have a problem with Cygwin. I am connecting from USA by ssh to the
> Hector supermachine in Edinburgh ( I write "startx" in Cygwin and then I
> use  "ssh -Y  v1aca...@login.hector.ac.uk" ). Everything works fine, the
> only problem is that the forwarding of the windows is very very slow. It
> takes sometimes also up to 5 minutes to open a new window. I am
> debugging a code with Totalview and it is a impossible to work. I am in
> contact with the Hector support and with their computer they tried to
> run Cygwin under windows and connecting by ssh (exactly like I am doing)
> and they say that x-forwarding  is fast.

The performance they're seeing probably has little to do with their
Cygwin version --- they're a lot closer, after all, so support's latency
is probably a lot lower.

NX actually works under Cygwin, though it's a pain to compile (and
unsupported I imagine). This document provides an introduction to
getting the system to work:

http://www.nomachine.com/documentation/building-components.php


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

Re: "run" changes behavior with cygwin-17.6

[Andy Koppe]

On 18 August 2010 15:51, Rodrigo Medina wrote:
> After upgrading to cygwin17.6 the program run changes behavior.
> For example:
> If I start mintty with the followin .bat
>
>       �...@echo off
>        C:
>        chdir \cygwin\bin
>        run mintty -e '/bin/bash' --login -i
>        exit
>
> In the mintty window that is started appears the following message:
>
> /bin/find: failed to restore initial working directory: No such file or
> directory

You can invoke mintty with the cmd.exe built-in 'start' instead of
'run'. Even better, just invoke it directly from a shortcut rather
than from a .bat script, which also avoids a console window flashing
up briefly. The 'mintty' package in setup.exe automatically creates a
suitable shortcut under Cygwin in the start menu.

Andy

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

Re: X-forwarding very very slow

[Larry Hall (Cygwin)]

On 8/18/2010 11:50 AM, Daniel Colascione wrote:

On 8/18/10 8:43 AM, Alberto Canestrelli wrote:

I have a problem with Cygwin. I am connecting from USA by ssh to the
Hector supermachine in Edinburgh ( I write "startx" in Cygwin and then I
use  "ssh -Y  v1aca...@login.hector.ac.uk" ). Everything works fine, the
only problem is that the forwarding of the windows is very very slow. It
takes sometimes also up to 5 minutes to open a new window. I am
debugging a code with Totalview and it is a impossible to work. I am in
contact with the Hector support and with their computer they tried to
run Cygwin under windows and connecting by ssh (exactly like I am doing)
and they say that x-forwarding  is fast.


The performance they're seeing probably has little to do with their
Cygwin version --- they're a lot closer, after all, so support's latency
is probably a lot lower.


Agreed.  I would point out, however, that the OPs Cygwin versions are
pretty out-of-date as well.  Though I'm not sure it will help in this
particular matter, it's worth thinking about upgrading.

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

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


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

Re: X-forwarding very very slow

[Csaba Raduly]

On Wed, Aug 18, 2010 at 5:43 PM, Alberto Canestrelli wrote:
> Hi,
> I have a problem with Cygwin. I am connecting from USA by ssh to the Hector
> supermachine in Edinburgh ( I write "startx" in Cygwin and then I use  "ssh
> -Y  v1aca...@login.hector.ac.uk" ). Everything works fine, the only problem
> is that the forwarding of the windows is very very slow.

Hi Alberto,
It would be useful if you could try a non-Cygwin X server (e.g. a
Linux or Solaris workstation). If X from under Linux appears fast,
then the slowdown could be between your network card and display
(probably Cygwin's fault). If X from Linux is also slow, the problem
may be with the propagation of the X protocol between your network
card and Hector (probably not Cygwin's fault) .

-- 
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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

Re: "run" changes behavior with cygwin-17.6

[Charles Wilson]

On 8/18/2010 11:09 AM, Corinna Vinschen wrote:

Looks like the "run" tool now needs a call to

   CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd));

and then use win32_cwd in the call to CreateProcess.

See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api


Yep. run2 also needs a similar update.

Thanks for the heads up; I didn't really think about how the recent 
changes to cygwin's cwd handling would affect those two packages.


--
Chuck

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

Re: "run" changes behavior with cygwin-17.6

[David Rothenberger]

On 8/18/2010 10:12 AM, Charles Wilson wrote:
> On 8/18/2010 11:09 AM, Corinna Vinschen wrote:
>> Looks like the "run" tool now needs a call to
>>
>>CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd));
>>
>> and then use win32_cwd in the call to CreateProcess.
>>
>> See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api
> 
> Yep. run2 also needs a similar update.
> 
> Thanks for the heads up; I didn't really think about how the recent
> changes to cygwin's cwd handling would affect those two packages.

I noticed a similar change in cygstart, too. I used to have a script
that would cd to a directory and then run cygstart. After the upgrade to
1.7.6, this stopped working. I had to use the --directory switch to
cygstart to get the right behavior.

-- 
David Rothenberger    daver...@acm.org

micro:
Thinker toys.

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

Re: endless problems with SSHD - bug ??

[Bob Goldberg]

On 8/17/2010 Larry Hall wrote:
>On 8/17/2010 5:28 PM, Bob Goldberg wrote: 
>>
>>
>>I simply want to copy files from 1 pc to another using a script initiated
by
>>either a user or cron entry. Ideally this would happen using scp into a
>>chroot'ed environment.
>
>chroot on Cygwin is completely faked.  Don't use it.  It will cause
>headaches.
>
>
>As for your problem with ssh , you've apparently missed this
>appropriately titled tidbit in your googling:
>
>
>
>
>This may just be because you're trying to use 'rbash' as your login shell.
>I didn't test that theory.
>

Larry - Tx much for your reply...

well even if chroot is "faked" (not sure what that means) - I might still be
inclined to use it...

Unless - is there a way I can LIMIT activity to only "scp"?
AND - prevent accessing outside what would be my "jail"?

I certainly did miss that very well titled document - no wonder my searches
were fruitless!! :-)  I'll check to make sure the path is getting set
correctly. Although, if I get scp running like I want, then I no longer
need/care about resolving this problem

TIA - Bob

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

ImageMagick: More insufficient package dependencies

[William Blunn]

My apologies to all the folks NOT involved in maintaining the 
ImageMagick package, but there doesn't appear to be any defined process 
for reporting bugs which might narrow down the attention-grab to a more 
relevant set of people.


I had some insufficient package dependency problems wite ImageMagick a 
little while ago.


Now I am getting some more. It seems that ImageMagick actually depends 
on some parts of X, but there is no relevant package dependency defined.


---8<---snip-here---
$ convert
/usr/bin/convert.exe: error while loading shared libraries: ?: cannot 
open shared object file: No such file or directory

$ cygcheck.exe convert
Found: C:\cygwin\bin\convert.exe
Found: C:\cygwin\bin\convert.exe
Found: C:\Windows\system32\convert.exe
Found: C:\cygwin\bin\convert.exe
C:\cygwin\bin\convert.exe
  C:\cygwin\bin\cygwin1.dll
C:\Windows\system32\ADVAPI32.DLL
  C:\Windows\system32\ntdll.dll
  C:\Windows\system32\KERNEL32.dll
  C:\Windows\system32\RPCRT4.dll
  C:\cygwin\bin\cyggcc_s-1.dll
  C:\cygwin\bin\cygMagickCore-1.dll
C:\cygwin\bin\cyggomp-1.dll
C:\cygwin\bin\cygbz2-1.dll
C:\cygwin\bin\cygfontconfig-1.dll
  C:\cygwin\bin\cygexpat-1.dll
  C:\cygwin\bin\cygfreetype-6.dll
C:\cygwin\bin\cygz.dll
  C:\cygwin\bin\cygiconv-2.dll
C:\cygwin\bin\cygltdl-7.dll
C:\cygwin\bin\cygtiff-5.dll
  C:\cygwin\bin\cygjbig-2.dll
  C:\cygwin\bin\cygjpeg-7.dll
C:\Windows\system32\GDI32.dll
  C:\Windows\system32\USER32.dll
  C:\cygwin\bin\cygMagickWand-1.dll
cygcheck: track_down: could not find cygX11-6.dll

cygcheck: track_down: could not find cygXext-6.dll

cygcheck: track_down: could not find cygX11-6.dll
---8<---snip-here---

Regards,

Bill

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

Re: endless problems with SSHD - bug ??

[Larry Hall (Cygwin)]

On 8/18/2010 1:27 PM, Bob Goldberg wrote:

Larry - Tx much for your reply...

well even if chroot is "faked" (not sure what that means) - I might still be
inclined to use it...


fake == it does nothing.  chroot is barely more than an empty shell (no pun
intended).  You won't find anyone seriously recommending its use.


Unless - is there a way I can LIMIT activity to only "scp"?
AND - prevent accessing outside what would be my "jail"?

I certainly did miss that very well titled document - no wonder my searches
were fruitless!! :-)  I'll check to make sure the path is getting set
correctly. Although, if I get scp running like I want, then I no longer
need/care about resolving this problem


If you need to restrict access, your best bet is to use Windows permissions.

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

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


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

Re: ImageMagick: More insufficient package dependencies

[William Blunn]

I have now installed the packages libX11_6 and libXext6.

ImageMagick's "convert" is now working.

I suspect that the ImageMagick Cygwin package may need to be modified to 
make it depend on libX11_6 and libXext6.


Bill

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

Re: "run" changes behavior with cygwin-17.6

[Christopher Faylor]

On Wed, Aug 18, 2010 at 10:16:50AM -0700, David Rothenberger wrote:
>On 8/18/2010 10:12 AM, Charles Wilson wrote:
>> On 8/18/2010 11:09 AM, Corinna Vinschen wrote:
>>> Looks like the "run" tool now needs a call to
>>>
>>>CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd));
>>>
>>> and then use win32_cwd in the call to CreateProcess.
>>>
>>> See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api
>> 
>> Yep. run2 also needs a similar update.
>> 
>> Thanks for the heads up; I didn't really think about how the recent
>> changes to cygwin's cwd handling would affect those two packages.
>
>I noticed a similar change in cygstart, too. I used to have a script
>that would cd to a directory and then run cygstart. After the upgrade to
>1.7.6, this stopped working. I had to use the --directory switch to
>cygstart to get the right behavior.

Call me dense but I don't understand why any changes are needed.  If
you're cd'ed to a non-Cygwin-special location why doesn't stuff "just
work"?

cgf

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

Re: "run" changes behavior with cygwin-17.6

[Andy Koppe]

On 18 August 2010 18:16, David Rothenberger wrote:
> On 8/18/2010 10:12 AM, Charles Wilson wrote:
>> On 8/18/2010 11:09 AM, Corinna Vinschen wrote:
>>> Looks like the "run" tool now needs a call to
>>>
>>>    CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd));
>>>
>>> and then use win32_cwd in the call to CreateProcess.
>>>
>>> See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api
>>
>> Yep. run2 also needs a similar update.
>>
>> Thanks for the heads up; I didn't really think about how the recent
>> changes to cygwin's cwd handling would affect those two packages.
>
> I noticed a similar change in cygstart, too. I used to have a script
> that would cd to a directory and then run cygstart. After the upgrade to
> 1.7.6, this stopped working. I had to use the --directory switch to
> cygstart to get the right behavior.

Ouch. This might affect even more cygutils. We really should have
thought of that.

At least there aren't any chdir() calls in any of the cygutils, so it
should primarily be a question of setting the Win32 current directory
in line with the POSIX one at startup, in any of the utils that may
invoke a Win32 function with a relative path. Chuck, do you need a
hand with going through them?

Andy

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

Re: ImageMagick: More insufficient package dependencies

[Christopher Faylor]

On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote:
>My apologies to all the folks NOT involved in maintaining the 
>ImageMagick package, but there doesn't appear to be any defined process 
>for reporting bugs which might narrow down the attention-grab to a more 
>relevant set of people.

Actually, this is the defined way to report bugs in a cygwin package.

cgf

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

Re: "run" changes behavior with cygwin-17.6

[Andy Koppe]

On 18 August 2010 19:24, Christopher Faylor wrote:
>>I noticed a similar change in cygstart, too. I used to have a script
>>that would cd to a directory and then run cygstart. After the upgrade to
>>1.7.6, this stopped working. I had to use the --directory switch to
>>cygstart to get the right behavior.
>
> Call me dense but I don't understand why any changes are needed.  If
> you're cd'ed to a non-Cygwin-special location why doesn't stuff "just
> work"?

The Win32 working directory is changed to '\\?\PIPE\' at process
startup, otherwise the working directory can't be deleted from under
the process, which you can do on Linux.

Andy

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

Re: Emacs and DBUS

[Michael Albinus]

Ken Brown  writes:

> Yes, I've just checked that it builds with D-Bus.  I'll upload a test
> release in a few days.  BTW, the configure script gives the following
> warning:
>
>   D-Bus integration has been tested for GNU/Linux only.
>
> So I don't know if it will work.

This message is from me (I wrote the D-Bus integration for Emacs). It
works for other Unices as well; if your test build runs also
successfully, it might be time to remove the warning.

Don't hesitate to contact me if you run into trouble.

> Ken

Best regards, Michael.

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

Re: "run" changes behavior with cygwin-17.6

[Charles Wilson]

On 8/18/2010 1:12 PM, Charles Wilson wrote:

On 8/18/2010 11:09 AM, Corinna Vinschen wrote:

Looks like the "run" tool now needs a call to

CYGWIN_CONV_TO_POSIX_PATH ((get_cwd (), win32_cwd));

and then use win32_cwd in the call to CreateProcess.

See http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api


Yep. run2 also needs a similar update.

Thanks for the heads up; I didn't really think about how the recent
changes to cygwin's cwd handling would affect those two packages.


The following patch seems to fix it for me. There will still be problems 
if the win32-converted cwd is (a) longer than 259 chars, or (b) derived 
from a cygwin-specific "virtual" path.


I don't want to duplicate all of cygwin's spawn_guts functionality in 
run, run2, and cygstart, so I think (a) and (b) are acceptable. After 
all, USUALLY you will invoke these tools via double-clicking some 
icon...so cygwin-specific or too-long paths are not an issue.


--
Chuck
Index: src/run.c
===
RCS file: /cvs/cygwin-apps/run/src/run.c,v
retrieving revision 1.10
diff -u -p -r1.10 run.c
--- src/run.c   2 Dec 2009 02:51:54 -   1.10
+++ src/run.c   18 Aug 2010 18:35:47 -
@@ -198,6 +198,33 @@ WinMain (HINSTANCE hSelf, HINSTANCE hPre
  {
STARTUPINFO start;
PROCESS_INFORMATION child;
+#if defined(__CYGWIN__)
+   /* Special CWD handling needed when calling CreateProcess() from a
+   * cygwin program, when cygwin kernel is 1.7.6 or above. See 
discussion
+   * in the following threads:
+   *   http://cygwin.com/ml/cygwin/2010-08/msg00205.html
+   *   http://cygwin.com/ml/cygwin-developers/2010-08/msg2.html
+   */
+   char * win32_cwd;
+   long size;
+   char *posix_buf;
+   char *posix_cwd = NULL;
+   size = pathconf(".", _PC_PATH_MAX);
+   if ((posix_buf = (char *)malloc((size_t)size)) != NULL)
+ {
+   posix_cwd = getcwd(posix_buf, (size_t)size);
+   if (posix_cwd)
+ {
+# if defined(HAVE_DECL_CYGWIN_CONV_PATH)
+   win32_cwd = (char *) cygwin_create_path 
(CCP_POSIX_TO_WIN_A, (void *) posix_cwd);
+# else
+   win32_cwd = (char *) malloc (MAX_PATH);
+   if (win32_cwd)
+ cygwin_conv_to_win32_path (posix_cwd, win32_cwd);
+# endif
+ }
+ }
+#endif
ZeroMemory( &child, sizeof(PROCESS_INFORMATION) );
ZeroMemory (&start, sizeof (STARTUPINFO));
start.cb = sizeof (STARTUPINFO);
@@ -209,9 +236,26 @@ WinMain (HINSTANCE hSelf, HINSTANCE hPre
FALSE,   /* handles are NOT inherited,  */
0,   /* creation flags  */
NULL,/* use parent's environment*/
-   NULL,/* use parent's current directory  */
+#if defined(__CYGWIN__)
+   win32_cwd, /* working directory; may be null*/
+#else
+   NULL,/* use parent's working directory  */
+#endif
&start,  /* STARTUPINFO pointer */
&child); /* receives PROCESS_INFORMATION*/
+#if defined(__CYGWIN__)
+   if (win32_cwd)
+ {
+   free (win32_cwd);
+   win32_cwd = NULL;
+ }
+   if (posix_buf)
+ {
+   free (posix_buf);
+   posix_buf = NULL;
+   posix_cwd = NULL;
+ }
+#endif
if (ret_code == 0)
  {
Trace(("getlasterror: %d\n", GetLastError()));


run.exe.bz2
Description: Binary data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: "run" changes behavior with cygwin-17.6

[Christopher Faylor]

On Wed, Aug 18, 2010 at 07:32:40PM +0100, Andy Koppe wrote:
>On 18 August 2010 19:24, Christopher Faylor wrote:
>>>I noticed a similar change in cygstart, too. I used to have a script
>>>that would cd to a directory and then run cygstart. After the upgrade to
>>>1.7.6, this stopped working. I had to use the --directory switch to
>>>cygstart to get the right behavior.
>>
>> Call me dense but I don't understand why any changes are needed. ??If
>> you're cd'ed to a non-Cygwin-special location why doesn't stuff "just
>> work"?
>
>The Win32 working directory is changed to '\\?\PIPE\' at process
>startup, otherwise the working directory can't be deleted from under
>the process, which you can do on Linux.

Yes, I guess I did not properly appreciate the fact that we presumably
broke every CreateProcess call in a cygwin program when we did this.
While I'm on record about not caring too much about that scenario, it
seems meaner than usual for us to break this since the report which
caused the recent change was from someone calling CreateProcess in a
cygwin program.

But, anyway, since we have broken this, I don't think we should force
every user of CreateProcess to call CYGWIN_CONV_TO_POSIX_PATH.  We
probably should add an internal interface which sets the current working
directory for windows if it can.

cgf

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

Re: "run" changes behavior with cygwin-17.6

[Charles Wilson]

On 8/18/2010 2:25 PM, Andy Koppe wrote:

Ouch. This might affect even more cygutils. We really should have
thought of that.

At least there aren't any chdir() calls in any of the cygutils, so it
should primarily be a question of setting the Win32 current directory
in line with the POSIX one at startup, in any of the utils that may
invoke a Win32 function with a relative path. Chuck, do you need a
hand with going through them?


Oh, right.

The problem is this: since the win32 CWD is *always* bogus, it is 
possible that other win32 functions will croak, not just CreateProcess. 
 So, there are a number of native win32 calls in the cygutils tools, like:


cygstart: CreateProcess, among others
lpr: ...many...
putclip/getclip: GetClipboardData, SetClipboardData, etc

Now, I haven't tested each of these tools exhaustively under 
cygwin-1.7.6, so I'm not sure the bogus win32 cwd affects them (except 
obviously cygstart).  But...by their very nature many of these tools use 
the native w32api.  So...each should probably take care to set the win32 
cwd if at all possible.



Yeah, patches would be great.

--
Chuck

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

Re: Emacs and DBUS

[Ken Brown]

On 8/18/2010 2:43 PM, Michael Albinus wrote:

Ken Brown writes:


Yes, I've just checked that it builds with D-Bus.  I'll upload a test
release in a few days.  BTW, the configure script gives the following
warning:

   D-Bus integration has been tested for GNU/Linux only.

So I don't know if it will work.


This message is from me (I wrote the D-Bus integration for Emacs). It
works for other Unices as well; if your test build runs also
successfully, it might be time to remove the warning.

Don't hesitate to contact me if you run into trouble.


Thanks, Michael.  I don't use D-BUS myself, but I hope the OP will test 
it and report back.


Ken

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

Re: "run" changes behavior with cygwin-17.6

[Corinna Vinschen]

On Aug 18 14:54, Christopher Faylor wrote:
> On Wed, Aug 18, 2010 at 07:32:40PM +0100, Andy Koppe wrote:
> >On 18 August 2010 19:24, Christopher Faylor wrote:
> >>>I noticed a similar change in cygstart, too. I used to have a script
> >>>that would cd to a directory and then run cygstart. After the upgrade to
> >>>1.7.6, this stopped working. I had to use the --directory switch to
> >>>cygstart to get the right behavior.
> >>
> >> Call me dense but I don't understand why any changes are needed. ??If
> >> you're cd'ed to a non-Cygwin-special location why doesn't stuff "just
> >> work"?
> >
> >The Win32 working directory is changed to '\\?\PIPE\' at process
> >startup, otherwise the working directory can't be deleted from under
> >the process, which you can do on Linux.
> 
> Yes, I guess I did not properly appreciate the fact that we presumably
> broke every CreateProcess call in a cygwin program when we did this.
> While I'm on record about not caring too much about that scenario, it
> seems meaner than usual for us to break this since the report which
> caused the recent change was from someone calling CreateProcess in a
> cygwin program.
> 
> But, anyway, since we have broken this, I don't think we should force
> every user of CreateProcess to call CYGWIN_CONV_TO_POSIX_PATH.  We
> probably should add an internal interface which sets the current working
> directory for windows if it can.

I'm going to add a new call

  cygwin_internal (CW_SYNC_WINCWD);

which will do the same for the CWD as

  cygwin_internal (CW_SYNC_WINENV);

already does for the environment.  Dropping the environment had roughly
the same consequences way back when, after all.

However, in contrast to CW_SYNC_WINENV, CW_SYNC_WINCWD will return -1
and set errno if setting a Windows CWD fails.  The error codes will be
typically

  ENOTDIR   if the CWD is a virtual directory
  EACCESif the directory is actually inaccessible or
  ENAMETOOLONG  if the directory has a pathname > 258 chars.

I'll also add documentation for this.


HTH,
Corinna

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

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

Re: "run" changes behavior with cygwin-17.6

[Christopher Faylor]

On Wed, Aug 18, 2010 at 09:13:40PM +0200, Corinna Vinschen wrote:
>On Aug 18 14:54, Christopher Faylor wrote:
>> On Wed, Aug 18, 2010 at 07:32:40PM +0100, Andy Koppe wrote:
>> >On 18 August 2010 19:24, Christopher Faylor wrote:
>> >>>I noticed a similar change in cygstart, too. I used to have a script
>> >>>that would cd to a directory and then run cygstart. After the upgrade to
>> >>>1.7.6, this stopped working. I had to use the --directory switch to
>> >>>cygstart to get the right behavior.
>> >>
>> >> Call me dense but I don't understand why any changes are needed. ??If
>> >> you're cd'ed to a non-Cygwin-special location why doesn't stuff "just
>> >> work"?
>> >
>> >The Win32 working directory is changed to '\\?\PIPE\' at process
>> >startup, otherwise the working directory can't be deleted from under
>> >the process, which you can do on Linux.
>> 
>> Yes, I guess I did not properly appreciate the fact that we presumably
>> broke every CreateProcess call in a cygwin program when we did this.
>> While I'm on record about not caring too much about that scenario, it
>> seems meaner than usual for us to break this since the report which
>> caused the recent change was from someone calling CreateProcess in a
>> cygwin program.
>> 
>> But, anyway, since we have broken this, I don't think we should force
>> every user of CreateProcess to call CYGWIN_CONV_TO_POSIX_PATH.  We
>> probably should add an internal interface which sets the current working
>> directory for windows if it can.
>
>I'm going to add a new call
>
>  cygwin_internal (CW_SYNC_WINCWD);
>
>which will do the same for the CWD as
>
>  cygwin_internal (CW_SYNC_WINENV);

Actually I just checked in "CW_SETCWD" which just calls
SetCurrentDirectoryW.  I was just going to request trying a snapshot
when I saw your message.

>already does for the environment.  Dropping the environment had roughly
>the same consequences way back when, after all.

Except that not every program uses the windows environment.  This affects
quite a few native windows calls.

cgf

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

Re: Emacs and DBUS

[Michael Albinus]

Ken Brown  writes:

> Thanks, Michael.  I don't use D-BUS myself, but I hope the OP will
> test it and report back.

It's some years ago I have used Cygwin. But if you have uploaded the
build already, I could check, whether I have problems running Emacs +
D-Bus under Cygwin.

> Ken

Best regards, Michael.

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

Re: "run" changes behavior with cygwin-17.6

[Christopher Faylor]

On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote:
>>already does for the environment.  Dropping the environment had roughly
>>the same consequences way back when, after all.
>
>Except that not every program uses the windows environment.  This affects
>quite a few native windows calls.

And, for that reason, I think we should reconsider this change.  Maybe
as a compromise maybe we could at least avoid cd'ing to the dummy
location on entry to the first cygwin program.

cgf

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

Re: "run" changes behavior with cygwin-17.6

[Corinna Vinschen]

On Aug 18 15:22, Christopher Faylor wrote:
> On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote:
> >>already does for the environment.  Dropping the environment had roughly
> >>the same consequences way back when, after all.
> >
> >Except that not every program uses the windows environment.  This affects
> >quite a few native windows calls.

It affects every program which calls CreateProcess or ShellExecute, for
instance.  This includes GDB, tcl, run, run2, cygstart, etc.

> And, for that reason, I think we should reconsider this change.  Maybe
> as a compromise maybe we could at least avoid cd'ing to the dummy
> location on entry to the first cygwin program.

I disagree.  When do you change the directory to //?/pipe then?  The
first time chdir is called?


Corinna

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

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

Re: "run" changes behavior with cygwin-17.6

[Corinna Vinschen]

On Aug 18 15:19, Christopher Faylor wrote:
> On Wed, Aug 18, 2010 at 09:13:40PM +0200, Corinna Vinschen wrote:
> >I'm going to add a new call
> >
> >  cygwin_internal (CW_SYNC_WINCWD);
> >
> >which will do the same for the CWD as
> >
> >  cygwin_internal (CW_SYNC_WINENV);
> 
> Actually I just checked in "CW_SETCWD" which just calls
> SetCurrentDirectoryW.  I was just going to request trying a snapshot
> when I saw your message.

Oh.  Shouldn't SetCurrentDirectoryW only be called if cygheap->cwd.get_error
is 0?  Here's what I had in mind:

Index: external.cc
===
RCS file: /cvs/src/src/winsup/cygwin/external.cc,v
retrieving revision 1.116
diff -u -p -r1.116 external.cc
--- external.cc 4 Jul 2010 17:12:26 -   1.116
+++ external.cc 18 Aug 2010 19:37:33 -
@@ -162,6 +162,24 @@ sync_winenv ()
   free (envblock);
 }
 
+/* Synchronize Win32 CWD with Cygwin CWD.  Return -1 and set errno if
+   setting the Win32 CWD fails. */
+static unsigned long
+sync_wincwd ()
+{
+  if (cygheap->cwd.get_error ())
+{
+  set_errno (cygheap->cwd.get_error ());
+  return (unsigned long) -1;
+}
+  if (!SetCurrentDirectoryW (cygheap->cwd.win32.Buffer))
+{
+  __seterrno ();
+  return (unsigned long) -1;
+}
+  return 0;
+}
+
 /*
  * Cygwin-specific wrapper for win32 ExitProcess and TerminateProcess.
  * It ensures that the correct exit code, derived from the specified
@@ -514,6 +532,9 @@ cygwin_internal (cygwin_getinfo_types t,
  res = (uintptr_t) strerror (err);
}
break;
+  case CW_SYNC_WINCWD:
+   res = sync_wincwd ();
+   break;
 
   default:
set_errno (ENOSYS);


Corinna

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

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

Re: "run" changes behavior with cygwin-17.6

[Christopher Faylor]

On Wed, Aug 18, 2010 at 09:34:46PM +0200, Corinna Vinschen wrote:
>On Aug 18 15:22, Christopher Faylor wrote:
>> On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote:
>> >>already does for the environment.  Dropping the environment had roughly
>> >>the same consequences way back when, after all.
>> >
>> >Except that not every program uses the windows environment.  This affects
>> >quite a few native windows calls.
>
>It affects every program which calls CreateProcess or ShellExecute, for
>instance.  This includes GDB, tcl, run, run2, cygstart, etc.

And, the current change affects every one of those programs and more.

>> And, for that reason, I think we should reconsider this change.  Maybe
>> as a compromise maybe we could at least avoid cd'ing to the dummy
>> location on entry to the first cygwin program.
>
>I disagree.  When do you change the directory to //?/pipe then?  The
>first time chdir is called?

Yes.

cgf

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

Re: "run" changes behavior with cygwin-17.6

[Corinna Vinschen]

On Aug 18 21:34, Corinna Vinschen wrote:
> On Aug 18 15:22, Christopher Faylor wrote:
> > On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote:
> > >>already does for the environment.  Dropping the environment had roughly
> > >>the same consequences way back when, after all.
> > >
> > >Except that not every program uses the windows environment.  This affects
> > >quite a few native windows calls.
> 
> It affects every program which calls CreateProcess or ShellExecute, for
> instance.  This includes GDB, tcl, run, run2, cygstart, etc.

Chuck, btw., the function setup_win_environ() in run.c can easily be
replaced with `cygwin_internal (CW_SYNC_WINENV);'


Corinna

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

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

Re: "run" changes behavior with cygwin-17.6

[Andy Koppe]

On 18 August 2010 20:39, Christopher Faylor wrote:
> On Wed, Aug 18, 2010 at 09:34:46PM +0200, Corinna Vinschen wrote:
>>On Aug 18 15:22, Christopher Faylor wrote:
>>> On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote:
>>> >>already does for the environment.  Dropping the environment had roughly
>>> >>the same consequences way back when, after all.
>>> >
>>> >Except that not every program uses the windows environment.  This affects
>>> >quite a few native windows calls.
>>
>>It affects every program which calls CreateProcess or ShellExecute, for
>>instance.  This includes GDB, tcl, run, run2, cygstart, etc.
>
> And, the current change affects every one of those programs and more.

Right, that's a pretty big argument for favouring Windows integration
rather than Linux compatibility here. So what would be the
consequences of not allowing the current working directory of a
running process to be deleted?

>>> And, for that reason, I think we should reconsider this change.  Maybe
>>> as a compromise maybe we could at least avoid cd'ing to the dummy
>>> location on entry to the first cygwin program.
>>
>>I disagree.  When do you change the directory to //?/pipe then?  The
>>first time chdir is called?
>
> Yes.

I'm not convinced such a compromise would be worthwhile, because it
would forfeit Linux compatibility while still breaking some
Win32-using programs. I think it should be one way or the other:
either stick with the current approach, or always sync the Win32
working directory up-to-date (except when that's not possible).

Andy

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

Re: "run" changes behavior with cygwin-17.6

[Brian Ford]

On Wed, 18 Aug 2010, Corinna Vinschen wrote:

> On Aug 18 15:22, Christopher Faylor wrote:
> > On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote:
> > >>already does for the environment.  Dropping the environment had roughly
> > >>the same consequences way back when, after all.
> > >
> > >Except that not every program uses the windows environment.  This affects
> > >quite a few native windows calls.
>
> It affects every program which calls CreateProcess or ShellExecute, for
> instance.  This includes GDB, tcl, run, run2, cygstart, etc.
>
> > And, for that reason, I think we should reconsider this change.  Maybe
> > as a compromise maybe we could at least avoid cd'ing to the dummy
> > location on entry to the first cygwin program.
>
> I disagree.  When do you change the directory to //?/pipe then?  The
> first time chdir is called?

Can someone please remind me why you shouldn't change to that directory
only when SetCurrentDirectory would fail due to a long path, virtual
path, etc?  I think it was covered in the developer list, but I can't find
it right now.

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: "run" changes behavior with cygwin-17.6

[Charles Wilson]

On 8/18/2010 3:41 PM, Corinna Vinschen wrote:


Chuck, btw., the function setup_win_environ() in run.c can easily be
replaced with `cygwin_internal (CW_SYNC_WINENV);'


Yes, I was just looking at that. I think setup_win_environ (or its guts 
before some early refactoring) pre-dated CW_SYNC_WINENV.


Before removing it, I'll have to verify some things -- like whether 
that-cygwin-fork-we-don't-mention has CW_SYNC_WINENV, and how hard it 
would be to add if not -- since I want run to work "over there" too.



With respect to the orginal discussion that spawned this thread, I'm 
going to hold off on any changes to run/run2/cygutils until a consensus 
is reached regarding:

  1) what's going to happen "inside" cygwin wrt win32 cwd;
  2) what new APIs are provided
  3) and a project on how soon an official 1.7.7 will be released with
 those changes
and then evaluate how best to modify the client apps.

--
Chuck

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

Re: "run" changes behavior with cygwin-17.6

[Corinna Vinschen]

On Aug 18 20:47, Andy Koppe wrote:
> On 18 August 2010 20:39, Christopher Faylor wrote:
> > On Wed, Aug 18, 2010 at 09:34:46PM +0200, Corinna Vinschen wrote:
> >>On Aug 18 15:22, Christopher Faylor wrote:
> >>> On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote:
> >>> >>already does for the environment.  Dropping the environment had roughly
> >>> >>the same consequences way back when, after all.
> >>> >
> >>> >Except that not every program uses the windows environment.  This affects
> >>> >quite a few native windows calls.
> >>
> >>It affects every program which calls CreateProcess or ShellExecute, for
> >>instance.  This includes GDB, tcl, run, run2, cygstart, etc.
> >
> > And, the current change affects every one of those programs and more.
> 
> Right, that's a pretty big argument for favouring Windows integration
> rather than Linux compatibility here. So what would be the
> consequences of not allowing the current working directory of a
> running process to be deleted?
> 
> >>> And, for that reason, I think we should reconsider this change.  Maybe
> >>> as a compromise maybe we could at least avoid cd'ing to the dummy
> >>> location on entry to the first cygwin program.
> >>
> >>I disagree.  When do you change the directory to //?/pipe then?  The
> >>first time chdir is called?
> >
> > Yes.
> 
> I'm not convinced such a compromise would be worthwhile, because it
> would forfeit Linux compatibility while still breaking some
> Win32-using programs. I think it should be one way or the other:
> either stick with the current approach, or always sync the Win32
> working directory up-to-date (except when that's not possible).

The question here is a bit tricky, me thinks.

1) Do we want as much POSIX compatibility as possible?

2) Do we want POSIX compatibility but not compromise on Win32 compatibility?

3) Do we want as much POSIX compatibility as possible, but are willing
   to compromise if it breaks backward compatibility in the Win32 realms?

Right now I tend strongly to 1, but I'm still open to 3 if the problems
are really too heavy.


Corinna

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

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

Re: "run" changes behavior with cygwin-17.6

[Brian Ford]

On Wed, 18 Aug 2010, Brian Ford wrote:

> Can someone please remind me why you shouldn't change to that directory
> only when SetCurrentDirectory would fail due to a long path, virtual
> path, etc?  I think it was covered in the developer list, but I can't find
> it right now.

Nevermind, sigh...

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

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

Re: "run" changes behavior with cygwin-17.6

[Eric Blake]

On 08/18/2010 01:55 PM, Corinna Vinschen wrote:
>> I'm not convinced such a compromise would be worthwhile, because it
>> would forfeit Linux compatibility while still breaking some
>> Win32-using programs. I think it should be one way or the other:
>> either stick with the current approach, or always sync the Win32
>> working directory up-to-date (except when that's not possible).
> 
> The question here is a bit tricky, me thinks.
> 
> 1) Do we want as much POSIX compatibility as possible?

POSIX allows the refusal to delete an in-use directory; and Solaris NFS
mounts behave this way.  But since Linux can delete in-use directories
(where an in-use directory includes the condition of at least one
process owning that directory as its cwd), and cygwin emulates Linux
rather than POSIX, we can try harder if it makes sense.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: "run" changes behavior with cygwin-17.6

[Corinna Vinschen]

On Aug 18 14:49, Brian Ford wrote:
> On Wed, 18 Aug 2010, Corinna Vinschen wrote:
> 
> > On Aug 18 15:22, Christopher Faylor wrote:
> > > On Wed, Aug 18, 2010 at 03:19:06PM -0400, Christopher Faylor wrote:
> > > >>already does for the environment.  Dropping the environment had roughly
> > > >>the same consequences way back when, after all.
> > > >
> > > >Except that not every program uses the windows environment.  This affects
> > > >quite a few native windows calls.
> >
> > It affects every program which calls CreateProcess or ShellExecute, for
> > instance.  This includes GDB, tcl, run, run2, cygstart, etc.
> >
> > > And, for that reason, I think we should reconsider this change.  Maybe
> > > as a compromise maybe we could at least avoid cd'ing to the dummy
> > > location on entry to the first cygwin program.
> >
> > I disagree.  When do you change the directory to //?/pipe then?  The
> > first time chdir is called?
> 
> Can someone please remind me why you shouldn't change to that directory
> only when SetCurrentDirectory would fail due to a long path, virtual
> path, etc?  I think it was covered in the developer list, but I can't find
> it right now.

It breaks POSIX compatibility in terms of not being able to rename
or delete a directory which is the CWD of any process.


Corinna

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

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

Re: "run" changes behavior with cygwin-17.6

[Eric Blake]

On 08/18/2010 01:58 PM, Corinna Vinschen wrote:
>> Can someone please remind me why you shouldn't change to that directory
>> only when SetCurrentDirectory would fail due to a long path, virtual
>> path, etc?  I think it was covered in the developer list, but I can't find
>> it right now.
> 
> It breaks POSIX compatibility in terms of not being able to rename
> or delete a directory which is the CWD of any process.

It breaks Linux, but not POSIX, compatibility.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: "run" changes behavior with cygwin-17.6

[Corinna Vinschen]

On Aug 18 15:51, Charles Wilson wrote:
> On 8/18/2010 3:41 PM, Corinna Vinschen wrote:
> 
> >Chuck, btw., the function setup_win_environ() in run.c can easily be
> >replaced with `cygwin_internal (CW_SYNC_WINENV);'
> 
> Yes, I was just looking at that. I think setup_win_environ (or its
> guts before some early refactoring) pre-dated CW_SYNC_WINENV.
> 
> Before removing it, I'll have to verify some things -- like whether
> that-cygwin-fork-we-don't-mention has CW_SYNC_WINENV, and how hard
> it would be to add if not -- since I want run to work "over there"
> too.

CW_SYNC_WINENV is available since May 2006.  That's Cygwin 1.5.20-1.

> With respect to the orginal discussion that spawned this thread, I'm
> going to hold off on any changes to run/run2/cygutils until a
> consensus is reached regarding:
>   1) what's going to happen "inside" cygwin wrt win32 cwd;

I'm not sure yet.  Maybe we should really go cgf's idea to stick
to the Win32 CWD, as long as chdir isn't called the first time.

>   2) what new APIs are provided

In PM we agreed on my suggestion.  I just have to test and document
it first...

>   3) and a project on how soon an official 1.7.7 will be released with
>  those changes

I think 1.7.7 will be released rather very soon.  Maybe this weekend.


Corinna

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

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

Re: "run" changes behavior with cygwin-17.6

[Corinna Vinschen]

On Aug 18 13:57, Eric Blake wrote:
> On 08/18/2010 01:55 PM, Corinna Vinschen wrote:
> >> I'm not convinced such a compromise would be worthwhile, because it
> >> would forfeit Linux compatibility while still breaking some
> >> Win32-using programs. I think it should be one way or the other:
> >> either stick with the current approach, or always sync the Win32
> >> working directory up-to-date (except when that's not possible).
> > 
> > The question here is a bit tricky, me thinks.
> > 
> > 1) Do we want as much POSIX compatibility as possible?
> 
> POSIX allows the refusal to delete an in-use directory; and Solaris NFS
> mounts behave this way.  But since Linux can delete in-use directories
> (where an in-use directory includes the condition of at least one
> process owning that directory as its cwd), and cygwin emulates Linux
> rather than POSIX, we can try harder if it makes sense.

That lets me more tend to 3 now (cgf's idea to defer until the first
chdir).  I'm still chewing nails, though.


Corinna

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

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

Re: Upgrading to cygwin 1.7.6 vs gcc 4.5

[Andy Koppe]

On 18 August 2010 06:25, Andy Koppe wrote:
> On 18 August 2010 00:09, Eric Blake wrote:
>> On 08/17/2010 04:54 PM, Ross Smith wrote:
>>> I've installed the experimental gcc 4.5 packages (because that's the
>>> version I'm using in all my other development environments, and it's
>>> nice not to have to target multiple compiler versions any more), but now
>>> that cygwin dll 1.7.6 is out, I can't seem to find a way to upgrade
>>> cygwin without also downgrading gcc. In the installer, if I select
>>> Current I get the new cygwin but the old gcc, while if I select
>>> Experimental, it keeps the new gcc but doesn't offer me the new cygwin.
>>>
>>> At the moment I'm sticking with the old cygwin, because the gcc upgrade
>>> is more important to me than the cygwin upgrade. Is there some way I'm
>>> missing to select both, or do I just have to accept that I can't upgrade
>>> anything else until the official gcc 4.5 is ready?
>>
>> Stay on the 'Curr' (not 'Exp'), click 'View' until you are on the
>> Pending page, then cycle on the string next to each gcc package until it
>> says Keep instead of the downgraded version number.
>
> I'd recommend selecting the 'Exp' button actually. That ensures that
> all dependencies of gcc, e.g. libgcc and libffi, are upgraded to 4.5
> too. (It's yet another flaw of setup.exe that it doesn't automatically
> upgrade dependencies of experimental versions accordingly.)

Scratch that. I hadn't realised that if you select 'Exp',
non-experimental packages no longer get updated, which of course is
exactly what the OP was saying. This is awful.

Andy

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

Re: ImageMagick: More insufficient package dependencies

[William Blunn]

On 18/08/2010 19:26, Christopher Faylor wrote:

On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote:
   

My apologies to all the folks NOT involved in maintaining the ImageMagick 
package, but there doesn't appear to be any defined process for reporting bugs 
which might narrow down the attention-grab to a more relevant set of people.
 

Actually, this is the defined way to report bugs in a cygwin package.
   


A I see. It's /defined/ to be mediocre.

Rather than attempting to solve the problem head-on, redefine the 
problem domain so that the problem is already solved.


Inspired.

Bill

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

Re: ImageMagick: More insufficient package dependencies

[Christopher Faylor]

On Wed, Aug 18, 2010 at 09:32:50PM +0100, William Blunn wrote:
>On 18/08/2010 19:26, Christopher Faylor wrote:
>> On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote:
>>>My apologies to all the folks NOT involved in maintaining the
>>>ImageMagick package, but there doesn't appear to be any defined process
>>>for reporting bugs which might narrow down the attention-grab to a more
>>>relevant set of people.
>>>
>>Actually, this is the defined way to report bugs in a cygwin package.
>
>A I see.  It's /defined/ to be mediocre.

For *you*, since you've decided to be insulting, you can actually expect
less-than-mediocre handling of your problems, this being a volunteer
process and human nature being what it is and all.

cgf

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

Re: ImageMagick: More insufficient package dependencies

[Corinna Vinschen]

On Aug 18 21:32, William Blunn wrote:
> On 18/08/2010 19:26, Christopher Faylor wrote:
> >On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote:
> >>My apologies to all the folks NOT involved in maintaining the ImageMagick 
> >>package, but there doesn't appear to be any defined process for reporting 
> >>bugs which might narrow down the attention-grab to a more relevant set of 
> >>people.
> >Actually, this is the defined way to report bugs in a cygwin package.
> 
> A I see. It's /defined/ to be mediocre.
> 
> Rather than attempting to solve the problem head-on, redefine the
> problem domain so that the problem is already solved.
> 
> Inspired.

Is there something in the water lately, which makes people on the
list more aggressive than usual?

It hasn't been redefined at all.  It's the common way of reporting
problems for a long time: http://cygwin.com/problems.html

If you don't like it, I'm sorry.  Are you going to volunteer to
maintain a Cygwin packages bug-tracking system?


Corinna

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

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

Re: ImageMagick: More insufficient package dependencies

[Andy Koppe]

On 18 August 2010 21:50, Corinna Vinschen wrote:
> On Aug 18 21:32, William Blunn wrote:
>> On 18/08/2010 19:26, Christopher Faylor wrote:
>> >On Wed, Aug 18, 2010 at 06:40:17PM +0100, William Blunn wrote:
>> >>My apologies to all the folks NOT involved in maintaining the ImageMagick 
>> >>package, but there doesn't appear to be any defined process for reporting 
>> >>bugs which might narrow down the attention-grab to a more relevant set of 
>> >>people.
>> >Actually, this is the defined way to report bugs in a cygwin package.
>>
>> A I see. It's /defined/ to be mediocre.
>>
>> Rather than attempting to solve the problem head-on, redefine the
>> problem domain so that the problem is already solved.
>>
>> Inspired.
>
> Is there something in the water lately, which makes people on the
> list more aggressive than usual?
>
> It hasn't been redefined at all.  It's the common way of reporting
> problems for a long time: http://cygwin.com/problems.html
>
> If you don't like it, I'm sorry.  Are you going to volunteer to
> maintain a Cygwin packages bug-tracking system?

Besides, thanks to the magic of mail filters, grabbing the attention
of a package maintainer isn't the problem anyway. The issue is whether
there's an active maintainer in the first place.

Andy

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

Re: Emacs and DBUS

[Ken Brown]

On 8/18/2010 3:19 PM, Michael Albinus wrote:

Ken Brown  writes:


Thanks, Michael.  I don't use D-BUS myself, but I hope the OP will
test it and report back.


It's some years ago I have used Cygwin. But if you have uploaded the
build already, I could check, whether I have problems running Emacs +
D-Bus under Cygwin.


Yes, it's uploaded.  See

  http://cygwin.com/ml/cygwin-announce/2010-08/msg00020.html

Ken

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

Re: X-forwarding very very slow

[Jeremy Bopp]

On 8/18/2010 11:55 AM, Csaba Raduly wrote:
> On Wed, Aug 18, 2010 at 5:43 PM, Alberto Canestrelli wrote:
>> Hi,
>> I have a problem with Cygwin. I am connecting from USA by ssh to the Hector
>> supermachine in Edinburgh ( I write "startx" in Cygwin and then I use  "ssh
>> -Y  v1aca...@login.hector.ac.uk" ). Everything works fine, the only problem
>> is that the forwarding of the windows is very very slow.
> 
> Hi Alberto,
> It would be useful if you could try a non-Cygwin X server (e.g. a
> Linux or Solaris workstation). If X from under Linux appears fast,
> then the slowdown could be between your network card and display
> (probably Cygwin's fault). If X from Linux is also slow, the problem
> may be with the propagation of the X protocol between your network
> card and Hector (probably not Cygwin's fault) .

You could also try enabling compression with -C.  I have found this to
be a necessity when connecting with X over ssh between work and home
even though the locations are quite near each other and plain text based
ssh access runs fine without the compression.

-Jeremy

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

RE: Postinstall for mintty fails when installing "just for me"

[Buchbinder, Barry (NIH/NIAID) [E]]

Corinna Vinschen sent the following at Wednesday, August 18, 2010 4:43 AM
>
>That usually just means you don't have admin privs.

For the archive:  That is indeed the case.

>Here's the actual problem:
>  cygdrive prefix / system  binary,noacl,posix=0,auto
>
>The cygdrive prefix is set to the mount option "noacl".  So the
>output from getfacl or ls or stat for this directory shows just fake
>permissions based on the DOS R/O flag.
>
>You're not an admin, so you're not allowed to write to this directory,
>see the cacls output.  However, since the cygdrive prefix is mounted
>with "noacl", Cygwin tools just don't know it.

With "acl", I had been getting annoying error messages about copying
permissions with "cp -p" on some network drives, so I switched
everything to "noacl".  I'll try switching back to "acl", testing for
error messages, and going to "noacl" only on drives that seem to have
problems.

Thanks for your input.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Re: "run" changes behavior with cygwin-17.6

[Daniel Colascione]

On 8/18/10 1:19 PM, Corinna Vinschen wrote:
>> POSIX allows the refusal to delete an in-use directory; and Solaris NFS
>> mounts behave this way.

What about renaming directories though? (Damn this tight coupling
Windows has between files and filenames.)

>>  But since Linux can delete in-use directories

Not just Linux -- OS X and the other BSDs too, presumably, allow
renaming and deleting directories that are the CWD of some process.

>> (where an in-use directory includes the condition of at least one
>> process owning that directory as its cwd), and cygwin emulates Linux
>> rather than POSIX, we can try harder if it makes sense.
> 
> That lets me more tend to 3 now (cgf's idea to defer until the first
> chdir).  I'm still chewing nails, though.

IMVHO, #1 is the right choice. It's a lot less surprising than #3, and
it fails safe. It's a very simple model: "relative filename use will
fail unless you do something special, and by doing something special,
you signify that you understand the magic." I can imagine #3 causing
subtle bugs in programs that only chdir() sometimes.

Using Win32 functions in a Cygwin program already requires extra
knowledge; adding CWD tracking doesn't hurt much.

The other crazy idea would be to override the Win32 file and path
functions and handle the notion of a current directory entirely within
Cygwin for both Win32 and Cygwin functions, but IIRC, playing games with
Windows API functions was explicitly rejected a while ago.

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

RE: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Buchbinder, Barry (NIH/NIAID) [E]]

Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:16 AM
>What changed since Cygwin 1.7.5:
>
>
>- Cygwin handles the current working directory entirely on its own.  The
>  Win32 current working directory is set to an invalid path to be out of
>  the way.  This affects calls to the Win32 file API (CreateFile, etc.).
>  See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api
 ^

In case you ever copy and paste the link, "htdocs/" needs to be deleted
for it to work.

Thanks for all you do for the cygwin community.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

RE: endless problems with SSHD - bug ??

[Bob Goldberg]

-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com]on Behalf
Of Larry Hall (Cygwin)
Sent: Wednesday, August 18, 2010 1:04 PM
To: cygwin@cygwin.com
Subject: Re: endless problems with SSHD - bug ??


On 8/18/2010 1:27 PM, Bob Goldberg wrote:
> Unless - is there a way I can LIMIT activity to only "scp"?
> AND - prevent accessing outside what would be my "jail"?
>
> I certainly did miss that very well titled document - no wonder my
searches
> were fruitless!! :-)  I'll check to make sure the path is getting set
> correctly. Although, if I get scp running like I want, then I no longer
> need/care about resolving this problem

If you need to restrict access, your best bet is to use Windows permissions.
=

OK Larry, 'nuf said on the sshd chroot :o)

permissions - no problem - got that covered already

STILL - can NOT get scp to work to save my life.
AFAIK - path DOES look good according to debug info.

i've changed my shell back to /bin/bash to eliminate that variable.
relevant reminders:
  using cygwin 1.7.6 on win2k; using RSA-keys for auth
  $ ssh a...@cappy # WORKS GREAT (no typing - RSA auth works)
  $ ssh a...@cappy "echo hello"   # fails in same manner as scp below
and so my scp command continues to give:
>> BEGIN screen dump
$ scp puttest.txt a...@cappy:~/
debug1: permanently_set_uid: 3945/514
debug3: Copy environment: ALLUSERSPROFILE=C:\\Documents and Settings\\All
Users
debug3: Copy environment: COMPUTERNAME=CAPPY
debug3: Copy environment: COMSPEC=C:\\WINNT\\system32\\cmd.exe
debug3: Copy environment: OS=Windows_NT
debug3: Copy environment:
PATH=/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cyg
drive/c/WINNT/System32/Wbem:/cygdrive/c/Program
Files/Symantec/pcAnywhere/:/bin
debug3: Copy environment:
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.W
SH
debug3: Copy environment: SYSTEMDRIVE=C:
debug3: Copy environment: SYSTEMROOT=C:\\WINNT
debug3: Copy environment: WINDIR=C:\\WINNT
debug3: Copy environment: CYGWIN=ntsec
getsockname failed: Socket operation on non-socket
getsockname failed: Socket operation on non-socket
Environment:
  ALLUSERSPROFILE=C:\Documents and Settings\All Users
  COMPUTERNAME=CAPPY
  COMSPEC=C:\WINNT\system32\cmd.exe
  OS=Windows_NT
 
PATH=/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32
/W
bem:/cygdrive/c/Program Files/Symantec/pcAnywhere/:/bin
  PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
  SYSTEMDRIVE=C:
  SYSTEMROOT=C:\WINNT
  WINDIR=C:\WINNT
  CYGWIN=ntsec
  USER=als
  LOGNAME=als
  HOME=/home/chroot/home/als
  MAIL=/var/spool/mail/als
  SHELL=/bin/bash
  SSH_CLIENT=192.168.1.156 3824 0
  SSH_CONNECTION=192.168.1.156 3824 UNKNOWN 0
debug3: channel 0: close_fds r -1 w -1 e -1
   1096 [main] sshd 1960 E:\cygwin\usr\sbin\sshd.exe: *** fatal error -
could no
t load user32, Win32 error 1114
Stack trace:
Frame Function  Args
00229E84  61004ADB  (61177840, 8000, , 61178977)
0022AEB4  61004ADB  (61178084, 61161E4C, 61161E4C, 0022AFA0)
0022AEE4  61001325  (61030A0B, 6123D224, 0022AF50, 0022AF18)
0022BBC8  6115764C  (0003, , , 61117A22)
0022BC08  610CADE3  (0003, 006BBAC8, 0022BD0C, 006C2998)
0022BC28  6102952B  (006BBAC8, 0022BD0C, 006C2998, 6115F410)
0022C148  610BFEA5  (006BB1F8, 0069B2C0, 0002, 0001)
0022C198  00412D4B  (006BB1F8, 0069B2C0, 006BB1F8, 00427EA2)
0022C1C8  004130F4  (006BB1F8, 0069B2C0, 006BF218, 006B290C)
0022C288  0041343C  (006BF258, 006BF218, 006BF218, 0001)
0022C2C8  0040AAF3  (0062, 000A, 006BCC38, 0040BB05)
0022C308  004389D6  (0001, , 006BCC38, 0040C6FA)
0022C348  0040BC6A  (006C2D48, 006BBA30, 0022C388, 00417DF6)
0022C388  00413CCE  (006C2D48, 0003, , 0022CC44)
0022CD58  004040F3  (, , 0022CD98, 61006C53)
0022CD98  61006C53  (, 0022CDD4, 610064F0, 7FFDF000)
End of stack trace (more stack frames may be present)
lost connection
<< END screen dump

and as I finish this - just had a h...
having cygwin installed on non- C: isn't a problem - is it??

TIA (again :)

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

All scripts in /etc/postinstall have wrong filetype

[Phil Goetz]

After running Cygwin setup to update my Cygwin install, I got a popup error, so 
I looked in /var/log/setup.log.  (BTW, it would be very helpful for the popup 
to say "Check /var/log/setup.log" instead of "Check setup.log".)

setup.log said, among other things:

2010/08/16 00:50:22 running: C:\cygwin\bin\bash.exe --norc --noprofile 
/etc/postinstall/update-info-dir.sh
2010/08/16 00:50:30 can't run /etc/postinstall/update-info-dir.sh: No such file
2010/08/16 00:50:30 running: C:\cygwin\bin\bash.exe --norc --noprofile 
/etc/postinstall/bash.sh
2010/08/16 00:50:30 can't run /etc/postinstall/bash.sh: No such file
2010/08/16 00:50:30 running: C:\cygwin\bin\bash.exe --norc --noprofile 
/etc/postinstall/docbook-xml42.sh
2010/08/16 00:50:30 abnormal exit: exit code=1

I looked in C:/cygwin/etc/postinstall.  Every single script there had ".done" 
appended to its name, eg

bash.sh => bash.sh.done

Hence none of the scripts could be run.

This is on Windows XP SP3, with an AMD64.
I think I downloaded files from ftp://mirror.cs.vt.edu, or possibly 
ftp.gtlib.gatech.edu .

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

Re: All scripts in /etc/postinstall have wrong filetype

[Andy Koppe]

On 19 August 2010 04:50, Phil Goetz wrote:
> After running Cygwin setup to update my Cygwin install, I got a popup error, 
> so I looked in /var/log/setup.log.  (BTW, it would be very helpful for the 
> popup to say "Check /var/log/setup.log" instead of "Check setup.log".)

Yep. That's already fixed in CVS.


> setup.log said, among other things:
>
> 2010/08/16 00:50:22 running: C:\cygwin\bin\bash.exe --norc --noprofile 
> /etc/postinstall/update-info-dir.sh
> 2010/08/16 00:50:30 can't run /etc/postinstall/update-info-dir.sh: No such 
> file
> 2010/08/16 00:50:30 running: C:\cygwin\bin\bash.exe --norc --noprofile 
> /etc/postinstall/bash.sh
> 2010/08/16 00:50:30 can't run /etc/postinstall/bash.sh: No such file
> 2010/08/16 00:50:30 running: C:\cygwin\bin\bash.exe --norc --noprofile 
> /etc/postinstall/docbook-xml42.sh
> 2010/08/16 00:50:30 abnormal exit: exit code=1
>
> I looked in C:/cygwin/etc/postinstall.  Every single script there had ".done" 
> appended to its name, eg
>
> bash.sh => bash.sh.done
>
> Hence none of the scripts could be run.

The .done is appended after a script has been run successfully. So the
question is why it tried to run scripts that had been run already.
Could you attach the log?

Andy

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

Re: Curious behavior of fifo on cygwin 1.7.5

[Etienne Carriere]

Hi,

Thanks for your answer . In order to have the standard behavior, I
open/close the filedescriptor before/after each read as in the
attached code and it seems to work

Regards,

Etienne Carrière

2010/8/17 Christopher Faylor :
> On Tue, Aug 17, 2010 at 07:25:25PM +0200, Etienne Carriere wrote:
>>Hello,
>>
>>I currently have a curious behavior with fifo (named pipes on cygwin
>>1.7.5) . I first discovered when using Nagios on cygwin but I achieved
>>to simplify it . The scenario is the following :
>
> If you search the mailing list archives, you'll see a fair number of
> problems with fifos and you'll also see my acknowledgement of same.
>
> fifos in Cygwin are a work-in-progress and are not guaranteed to work
> like their linux counterparts.
>
> I do poke at them from time to time but, for now, you'll have to
> consider them to be "as-is".  That means that some things are broken.
>
> cgf
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>


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

Re: "run" changes behavior with cygwin-17.6

[Christopher Faylor]

On Wed, Aug 18, 2010 at 05:42:21PM -0700, Daniel Colascione wrote:
>The other crazy idea would be to override the Win32 file and path
>functions and handle the notion of a current directory entirely within
>Cygwin for both Win32 and Cygwin functions, but IIRC, playing games with
>Windows API functions was explicitly rejected a while ago.

Right.  I suggested that in cygwin-developers but neither Corinna nor I
could really convince ourselves that it was a good idea.

cgf

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