On Sat, 9 Mar 2019, 02:50 Takashi Yano wrote:
> Hi Adnrew,
>
> On Fri, 08 Mar 2019 18:19:02 -0500 Andrew Schulman wrote:
> > OK. I rebuilt screen 4.6.2-2 and uploaded it as a test package. Please
> test it
> > and let me know if it fixes the problem.
>
> I have tested screen 4.6.2-2 and confirmed
Hi Adnrew,
On Fri, 08 Mar 2019 18:19:02 -0500 Andrew Schulman wrote:
> OK. I rebuilt screen 4.6.2-2 and uploaded it as a test package. Please test it
> and let me know if it fixes the problem.
I have tested screen 4.6.2-2 and confirmed the issue regarding
-Q option is solved.
Thank you for the q
> On Fri, 08 Mar 2019 12:57:20 -0500 Andrew Schulman wrote:
> > > any chance to rebuild screen with the patch from
> > > https://cygwin.com/ml/cygwin/2019-03/msg00167.html
> >
> > Sure, will do. Thanks to both of y'all for solving this.
>
> Due to:
> https://cygwin.com/ml/cygwin/2019-03/msg00176.
On Fri, 08 Mar 2019 12:57:20 -0500 Andrew Schulman wrote:
> > any chance to rebuild screen with the patch from
> > https://cygwin.com/ml/cygwin/2019-03/msg00167.html
>
> Sure, will do. Thanks to both of y'all for solving this.
Due to:
https://cygwin.com/ml/cygwin/2019-03/msg00176.html
the patch s
> Hi Andrew,
>
> On Mar 8 23:46, Takashi Yano wrote:
> > Hi Corinna,
> >
> > Thanks for your advice.
> >
> > On Fri, 8 Mar 2019 15:11:18 +0100 Corinna Vinschen wrote:
> > > > In Linux, connect() in the client returns befor the
> > > > server calls accept(). However, in cygwin, connect()
> > > >
On Mar 9 01:21, Takashi Yano wrote:
> On Fri, 8 Mar 2019 16:56:35 +0100 Corinna Vinschen wrote:
> > > Does this affect to listen() as well?
> >
> > No, listen isn't affected.
>
> The cause is failure of setsockopt().
> setsockopt() before accept() failed with EALREADY.
>
> I looked into fhandle
On Fri, 8 Mar 2019 16:56:35 +0100 Corinna Vinschen wrote:
> > Does this affect to listen() as well?
>
> No, listen isn't affected.
The cause is failure of setsockopt().
setsockopt() before accept() failed with EALREADY.
I looked into fhandler_sock_local.cc.
In fhandler_socket_local::af_local_se
On Mar 9 00:39, Takashi Yano wrote:
> Hi Corinna,
>
> On Fri, 8 Mar 2019 15:11:18 +0100 Corinna Vinschen wrote:
> > setsockopt (sock, SOL_SOCKET, SO_PEERCRED, NULL, 0);
> > before calling accept or connect.
>
> I added this to the test code but it failed as:
>
> Server: Created.
> Server: Bin
Hi Corinna,
On Fri, 8 Mar 2019 15:11:18 +0100 Corinna Vinschen wrote:
> setsockopt (sock, SOL_SOCKET, SO_PEERCRED, NULL, 0);
> before calling accept or connect.
I added this to the test code but it failed as:
Server: Created.
Server: Binded.
Server: Listened.
Client: Created.
Client: Connected
Hi Andrew,
On Mar 8 23:46, Takashi Yano wrote:
> Hi Corinna,
>
> Thanks for your advice.
>
> On Fri, 8 Mar 2019 15:11:18 +0100 Corinna Vinschen wrote:
> > > In Linux, connect() in the client returns befor the
> > > server calls accept(). However, in cygwin, connect()
> > > does not return until
Hi Corinna,
Thanks for your advice.
On Fri, 8 Mar 2019 15:11:18 +0100 Corinna Vinschen wrote:
> > In Linux, connect() in the client returns befor the
> > server calls accept(). However, in cygwin, connect()
> > does not return until the server calls accept().
>
> This is a result of the handshak
On Mar 8 23:01, Takashi Yano wrote:
> Hello,
>
> Thank you for the information.
>
> On Thu, 7 Mar 2019 18:24:45 +0300 Andrey Repin wrote:
> > > GNU screen freeze without much of an effort under Cygwin.
> > > Try detaching from running screen and then running screen -ls.
> >
> > Past discussion
Hello,
Thank you for the information.
On Thu, 7 Mar 2019 18:24:45 +0300 Andrey Repin wrote:
> > GNU screen freeze without much of an effort under Cygwin.
> > Try detaching from running screen and then running screen -ls.
>
> Past discussion
> http://sourceware.org/ml/cygwin/2017-05/msg00448.html
Greetings, Takashi Yano!
>> This also causes gnu screen to freeze.
> GNU screen freeze without much of an effort under Cygwin.
> Try detaching from running screen and then running screen -ls.
Past discussion
http://sourceware.org/ml/cygwin/2017-05/msg00448.html
mid:16810313565.20170527142...@yan
Sorry, the message bellow accidentally lost the references.
On Thu, 7 Mar 2019 20:14:39 +0900 Takashi Yano wrote:
> On Wed, 06 Mar 2019 19:33:17 +0100 Achim Gratz wrote:
> > This has been the case for as long as I use ssh logins and is by design.
> > You can drop privileges after logon (see cygdro
Greetings, Takashi Yano!
> This also causes gnu screen to freeze.
GNU screen freeze without much of an effort under Cygwin.
Try detaching from running screen and then running screen -ls.
> To reproduce this:
> (1) Start screen in mintty window.
> (2) Detatch from the screen (Ctrl-A d).
> (3) Log
On Wed, 06 Mar 2019 19:33:17 +0100 Achim Gratz wrote:
> This has been the case for as long as I use ssh logins and is by design.
> You can drop privileges after logon (see cygdrop), but not aquire new
> ones.
>
> So if that's changed behaviour for you, then your ssh logins didn't
> actually work t
Hi Corinna,
On Wed, 6 Mar 2019 17:17:31 +0100 Corinna Vinschen wrote:
> > This is by design, and this is no new behaviour. As soon as an admin
> > account logs in, seteuid uses the elevated token. Cygwin is doing that
> > since 2015.
>
> Actually, since 2010.
>
> > After all, from an ssh sessi
Takashi Yano writes:
> I would like to report a problem of recent cygwin.
>
> If a user logs in via ssh, the user aqcuires the elevated
> privilege if the user belongs to Administrators group.
This has been the case for as long as I use ssh logins and is by design.
You can drop privileges after lo
On Mar 6 17:15, Corinna Vinschen wrote:
> On Mar 7 01:00, Takashi Yano wrote:
> > Hello,
> >
> > I would like to report a problem of recent cygwin.
> >
> > If a user logs in via ssh, the user aqcuires the elevated
> > privilege if the user belongs to Administrators group.
>
> This is by design
On Mar 7 01:00, Takashi Yano wrote:
> Hello,
>
> I would like to report a problem of recent cygwin.
>
> If a user logs in via ssh, the user aqcuires the elevated
> privilege if the user belongs to Administrators group.
This is by design, and this is no new behaviour. As soon as an admin
accoun
Hello,
I would like to report a problem of recent cygwin.
If a user logs in via ssh, the user aqcuires the elevated
privilege if the user belongs to Administrators group.
The following log is the example of the behaviour.
[yano@Express5800-S70 ~]$ touch /cygdrive/c/windows/testfile
touch: canno
22 matches
Mail list logo
