*ps -ef* only shows /xterm /instances that are created by the window
manager, not those created by sshd - at least, not with the name "xterm".
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://
Rael
Sent: 14 February 2022 13:12
To: cygwin@cygwin.com
Subject: Re: sshd
[CAUTION: EXTERNAL SENDER]
On 2/13/22 10:56 PM, Andrey Repin wrote:
> Greetings, Ernie Rael!
>
> ...
> Open Windows Firewall (cygstart WF.msc), find all your sshd rules and
> trash them. Manually create (o
On 2/13/22 10:56 PM, Andrey Repin wrote:
Greetings, Ernie Rael!
...
Open Windows Firewall (cygstart WF.msc), find all your sshd rules and trash
them. Manually create (or tweak Windows sshd one) a single rule for port
rather than executable.
Additionally, to resolve conflicts with stock sshd
sed ssh locally under cygwin, primarily to get a term for a use
>>> with admin priv. And I can ssh from cygwin to the linux machine. On
>>> cygwin I see
>>>
>>> $ ps -ef |grep sshd
>>> cyg_serv 255 254 ? Feb 1 /usr/sbin/sshd
>&
On Sun, Feb 13, 2022 at 7:38 AM Ernie Rael wrote:
> Doesn't seem to be a firewall issue. NetStat took about 90 seconds.
>
> $ ps -lp 255
>PIDPPIDPGID WINPID TTY UIDSTIME COMMAND
>255 254 255 4176 ? 1006 Feb 1
&
Thanks Russell,
cygrunsrv's running
$ cygrunsrv --list
sshd
$ cygrunsrv --query sshd
Service : sshd
Display name : CYGWIN sshd
Current State : Running
Controls Accepted : Stop
Command : /usr/sbin/sshd -D
-ernie
On 2/12/22 10:30 PM, Russell VT wrote
to the linux machine. On
cygwin I see
$ ps -ef |grep sshd
cyg_serv 255 254 ? Feb 1 /usr/sbin/sshd
But ssh from linux to cygwin hangs (finally times out). Ping works
linux --> windows.
I must have run ssh-host-config way back when. Can I just run it again?
Suggesti
at *cygserver* and *cygrunsrv*, and NOT directly at sshd. It's
in /usr/sbin, generally.
Something like:
$ cygrunsrv --list
cygsshd
$ cygrunsrv --query cygsshd
Service : cygsshd
Display name: CYGWIN cygsshd
Current State : Stopped
Command : /usr/sbin/sshd -D
You
-ef |grep sshd
cyg_serv 255 254 ? Feb 1 /usr/sbin/sshd
But ssh from linux to cygwin hangs (finally times out). Ping works linux -->
windows.
I must have run ssh-host-config way back when. Can I just run it again?
Suggestions for something else to try and/or tri
Hi all,
I set up cygwin several years ago and have only had one system at home.
I've recently got a 2nd, linux.
I've used ssh locally under cygwin, primarily to get a term for a use
with admin priv. And I can ssh from cygwin to the linux machine. On
cygwin I see
$ ps -ef |grep sshd
Ken,
Thank you for the reply, this is great news!
Looking forward to speedier rsyncs with Cygwin.
Keith
On Thu, Sep 16, 2021, 16:49 Ken Brown via Cygwin wrote:
> On 9/16/2021 6:00 PM, Keith Christian via Cygwin wrote:
> > I've been following his thread with interest both here
On 9/16/2021 6:00 PM, Keith Christian via Cygwin wrote:
I've been following his thread with interest both here and on the Cygwin
developers list. I, too rsync between Cygwin and Linux machines.
Lots of good debate showing the genius of the folks that support the cygwin
infrastructure.
Looks
I've been following his thread with interest both here and on the Cygwin
developers list. I, too rsync between Cygwin and Linux machines.
Lots of good debate showing the genius of the folks that support the cygwin
infrastructure.
Looks like the lively discussion on both lists has stopped. What
On Sep 6 21:34, Brian Inglis wrote:
> On 2021-09-06 15:24, Ken Brown via Cygwin wrote:
> > On 9/6/2021 4:54 PM, Peter Dons Tychsen wrote:
> > > Hi there,
> > >
> > > On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
> > > > > No, wait. I get what you say. The optimzation settings
On 07/09/2021 23:44, Ken Brown via Cygwin wrote:
>
> MS can't add a new named field to a documented struct without
breaking a lot of code. I think it's extremely unlikely that they would
do that. On the other hand, I think it's very likely that a reader of
the Cygwin code would be confused by
On 9/7/2021 5:52 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
With undocumented structure member initialization an issue, maybe better to
future proof using e.g.
MEM_EXTENDED_PARAMETER mmap_ext = { 0 }; // or memset or bzero
I don't see what this would accomplish. We're already
> >
> > With undocumented structure member initialization an issue, maybe better to
> > future proof using e.g.
> >
> > MEM_EXTENDED_PARAMETER mmap_ext = { 0 }; // or memset or bzero
>
> I don't see what this would accomplish. We're already initializing every
> member
> after Corinna's
Hi Ken,
On Mon, 2021-09-06 at 17:24 -0400, Ken Brown via Cygwin wrote:
> You're looking at the wrong source code. The bug didn't occur until
> the code
> was changed to do the following:
You are right. I do not know why i looked at an old checkout of the
code. Shame on me! Sorry for wasting
On 9/6/2021 11:34 PM, Brian Inglis wrote:
On 2021-09-06 15:24, Ken Brown via Cygwin wrote:
On 9/6/2021 4:54 PM, Peter Dons Tychsen wrote:
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
No, wait. I get what you say. The optimzation settings of the test
case should
On 2021-09-06 15:24, Ken Brown via Cygwin wrote:
On 9/6/2021 4:54 PM, Peter Dons Tychsen wrote:
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
No, wait. I get what you say. The optimzation settings of the test
case should have no influence on the code inside the
On 9/6/2021 5:24 PM, Ken Brown via Cygwin wrote:
On 9/6/2021 4:54 PM, Peter Dons Tychsen wrote:
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
No, wait. I get what you say. The optimzation settings of the test
case should have no influence on the code inside the
On 9/6/2021 4:54 PM, Peter Dons Tychsen wrote:
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
No, wait. I get what you say. The optimzation settings of the test
case should have no influence on the code inside the DLL. That
doesn't
make sense for sure. However, I
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
> > No, wait. I get what you say. The optimzation settings of the test
> > case should have no influence on the code inside the DLL. That
> > doesn't
> > make sense for sure. However, I ran the testcase under GDB, I
Hi there,
On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote:
> > No, wait. I get what you say. The optimzation settings of the test
> > case should have no influence on the code inside the DLL. That
> > doesn't
> > make sense for sure. However, I ran the testcase under GDB, I
On 9/6/2021 2:07 PM, Corinna Vinschen via Cygwin wrote:
On Sep 6 19:59, Corinna Vinschen via Cygwin wrote:
On Sep 6 13:38, Ken Brown via Cygwin wrote:
On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote:
On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote:
On Sep 5 09:24, Ken Brown via
On Sep 6 19:59, Corinna Vinschen via Cygwin wrote:
> On Sep 6 13:38, Ken Brown via Cygwin wrote:
> > On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote:
> > > On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote:
> > > > On Sep 5 09:24, Ken Brown via Cygwin wrote:
> > > > > On 9/4/2021 8:04 PM,
On Sep 6 13:38, Ken Brown via Cygwin wrote:
> On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote:
> > On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote:
> > > On Sep 5 09:24, Ken Brown via Cygwin wrote:
> > > > On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote:
> > > > > On 9/4/2021 6:58 PM,
On 9/6/2021 1:38 PM, Ken Brown via Cygwin wrote:
On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote:
On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote:
On Sep 5 09:24, Ken Brown via Cygwin wrote:
On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote:
On 9/4/2021 6:58 PM, Ken Brown via Cygwin
On 9/6/2021 1:12 PM, Ken Brown via Cygwin wrote:
On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote:
On Sep 5 09:24, Ken Brown via Cygwin wrote:
On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote:
On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote:
Here are the correct commits:
8169e39ab
On 9/6/2021 11:32 AM, Corinna Vinschen via Cygwin wrote:
On Sep 5 09:24, Ken Brown via Cygwin wrote:
On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote:
On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote:
Here are the correct commits:
8169e39ab Cygwin: C++17: register keyword is deprecated
On Sep 5 09:24, Ken Brown via Cygwin wrote:
> On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote:
> > On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote:
> > > Here are the correct commits:
> > >
> > > 8169e39ab Cygwin: C++17: register keyword is deprecated
> > > 3ca80b360 Cygwin: dumper: fix up GCC
05.09.2021 17:11, Brian Inglis:
The suggestion was intended as a tip to ensure *complete* locally
rebuilt package contents are installed,
Setup has its "from_cwd" installation mode for precisely that reason:
installing a local package without the need to create a full install
hierarchy and
On 2021-09-05 02:18, Achim Gratz wrote:
04.09.2021 18:45, Brian Inglis:
[...]
then to install all binary packages for dogfooding:
Would you please stop telling folks to do things that potentially breaks
their systems?
There are quite a few more steps to take if you want to emulate what
On 9/4/2021 8:04 PM, Ken Brown via Cygwin wrote:
On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote:
On 9/4/2021 6:54 PM, Ken Brown via Cygwin wrote:
On 9/4/2021 6:37 PM, Ken Brown via Cygwin wrote:
I've reduced the procps failure to the following test case:
$ cat mmap_test.c
#include
#include
04.09.2021 18:45, Brian Inglis:
[...]
then to install all binary packages for dogfooding:
Would you please stop telling folks to do things that potentially breaks
their systems?
There are quite a few more steps to take if you want to emulate what
setup does. Then again you cannot do that
On 9/4/2021 6:58 PM, Ken Brown via Cygwin wrote:
On 9/4/2021 6:54 PM, Ken Brown via Cygwin wrote:
On 9/4/2021 6:37 PM, Ken Brown via Cygwin wrote:
I've reduced the procps failure to the following test case:
$ cat mmap_test.c
#include
#include
#include
int
main ()
{
void *addr;
int
On 2021-09-04 16:37, Ken Brown via Cygwin wrote:
I've reduced the procps failure to the following test case:
$ cat mmap_test.c
#include
#include
#include
int
main ()
{
void *addr;
int page_size = getpagesize ();
addr = mmap (0, page_size, PROT_READ | PROT_WRITE,
On 9/4/2021 6:54 PM, Ken Brown via Cygwin wrote:
On 9/4/2021 6:37 PM, Ken Brown via Cygwin wrote:
I've reduced the procps failure to the following test case:
$ cat mmap_test.c
#include
#include
#include
int
main ()
{
void *addr;
int page_size = getpagesize ();
addr = mmap (0,
On 9/4/2021 6:37 PM, Ken Brown via Cygwin wrote:
I've reduced the procps failure to the following test case:
$ cat mmap_test.c
#include
#include
#include
int
main ()
{
void *addr;
int page_size = getpagesize ();
addr = mmap (0, page_size, PROT_READ | PROT_WRITE,
I've reduced the procps failure to the following test case:
$ cat mmap_test.c
#include
#include
#include
int
main ()
{
void *addr;
int page_size = getpagesize ();
addr = mmap (0, page_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (addr ==
On 2021-09-03 14:59, Chris Roehrig wrote:
On Fri Sep 3 2021, at 12:55 PM, Corinna Vinschen wrote:
On Sep 2 12:03, Chris Roehrig wrote:
On Thu Sep 2 2021, at 8:25 AM, Ken Brown via Cygwin wrote:
On 9/1/2021 5:11 PM, Chris Roehrig wrote:
I rebuild procps 3.3.17.29-2480 from source and it
Am 03.09.2021 um 22:59 schrieb Chris Roehrig:
I got procps working I think (both with and without the revert).
That likely wasn't what Corinna wanted to know, though.
Please re-install the procps-ng, cygwin and cygwin-devel packages from
setup (and revert any other alterations you may have
On Fri Sep 3 2021, at 12:55 PM, Corinna Vinschen
wrote:
> [resent, this time with the ML in To]
>
> On Sep 2 12:03, Chris Roehrig wrote:
>>
>> On Thu Sep 2 2021, at 8:25 AM, Ken Brown via Cygwin
>> wrote:
>>> On 9/1/2021 5:11 PM, Chris Roehrig wrote:
I rebuild procps 3.3.17.29-2480
[resent, this time with the ML in To]
On Sep 2 12:03, Chris Roehrig wrote:
>
> On Thu Sep 2 2021, at 8:25 AM, Ken Brown via Cygwin wrote:
> > On 9/1/2021 5:11 PM, Chris Roehrig wrote:
> >> I rebuild procps 3.3.17.29-2480 from source and it appears to work, so
> >> maybe the stock procps
On 9/2/2021 3:03 PM, Chris Roehrig wrote:
On Thu Sep 2 2021, at 8:25 AM, Ken Brown via Cygwin wrote:
On 9/1/2021 5:11 PM, Chris Roehrig wrote:
I rebuild procps 3.3.17.29-2480 from source and it appears to work, so maybe
the stock procps package is incompatible with the current master
On Thu Sep 2 2021, at 8:25 AM, Ken Brown via Cygwin wrote:
> On 9/1/2021 5:11 PM, Chris Roehrig wrote:
>> I rebuild procps 3.3.17.29-2480 from source and it appears to work, so maybe
>> the stock procps package is incompatible with the current master branch.
>
> Maybe, but it could also be a
On 9/1/2021 5:11 PM, Chris Roehrig wrote:
I rebuild procps 3.3.17.29-2480 from source and it appears to work, so maybe
the stock procps package is incompatibility with the current master branch.
Maybe, but it could also be a Cygwin bug. I'll do a bisection of the Cygwin
sources to see if I
On Tue Aug 31 2021, at 12:05 PM, Ken Brown via Cygwin
>> wrote:
>>
>>> On 8/30/2021 7:58 PM, Chris Roehrig wrote:
>>>> I got it to build and tried out the topic/pipe branch (checked out on
>>>> Monday around 4:30pm PDT):
>>>> 1. I didn'
cygwin1.dll as installed by setup_
On Tue Aug 31 2021, at 12:05 PM, Ken Brown via Cygwin wrote:
On 8/30/2021 7:58 PM, Chris Roehrig wrote:
I got it to build and tried out the topic/pipe branch (checked out on Monday
around 4:30pm PDT):
1. I didn't see any improvement in my sshd+rsync time, still 3
gt;
> On Tue Aug 31 2021, at 12:05 PM, Ken Brown via Cygwin
> wrote:
>
>> On 8/30/2021 7:58 PM, Chris Roehrig wrote:
>>> I got it to build and tried out the topic/pipe branch (checked out on
>>> Monday around 4:30pm PDT):
>>> 1. I didn't see any improveme
ris Roehrig wrote:
>> I got it to build and tried out the topic/pipe branch (checked out on Monday
>> around 4:30pm PDT):
>> 1. I didn't see any improvement in my sshd+rsync time, still 3-4 MB/sec.
>> 2. I get the following error from procps: procps:ps/output.c:2195: pleas
On 8/30/2021 7:58 PM, Chris Roehrig wrote:
I got it to build and tried out the topic/pipe branch (checked out on Monday
around 4:30pm PDT):
1. I didn't see any improvement in my sshd+rsync time, still 3-4 MB/sec.
2. I get the following error from procps: procps:ps/output.c:2195: please
I got it to build and tried out the topic/pipe branch (checked out on Monday
around 4:30pm PDT):
1. I didn't see any improvement in my sshd+rsync time, still 3-4 MB/sec.
2. I get the following error from procps: procps:ps/output.c:2195: please
report this bug
(I also get this using
On Sun, 29 Aug 2021 22:15:29 -0400
Ken Brown wrote:
> On 8/29/2021 8:22 PM, Takashi Yano via Cygwin wrote:
> > On Mon, 30 Aug 2021 09:13:14 +0900
> > Takashi Yano wrote:
> >> On Sun, 29 Aug 2021 17:04:56 -0400
> >> Ken Brown wrote:
> >>> On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
>
On 8/29/2021 8:22 PM, Takashi Yano via Cygwin wrote:
On Mon, 30 Aug 2021 09:13:14 +0900
Takashi Yano wrote:
On Sun, 29 Aug 2021 17:04:56 -0400
Ken Brown wrote:
On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
On Sat, 28 Aug 2021
On Mon, 30 Aug 2021 09:13:14 +0900
Takashi Yano wrote:
> On Sun, 29 Aug 2021 17:04:56 -0400
> Ken Brown wrote:
> > On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
> > > On Sat, 28 Aug 2021 18:41:02 +0900
> > > Takashi Yano wrote:
> > >> On Sat, 28 Aug 2021 10:43:27 +0200
> > >> Corinna
On Sun, 29 Aug 2021 17:04:56 -0400
Ken Brown wrote:
> On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
> > On Sat, 28 Aug 2021 18:41:02 +0900
> > Takashi Yano wrote:
> >> On Sat, 28 Aug 2021 10:43:27 +0200
> >> Corinna Vinschen wrote:
> >>> On Aug 28 02:21, Takashi Yano via Cygwin wrote:
>
On 8/29/2021 4:41 AM, Takashi Yano wrote:
Hi Ken,
On Sat, 28 Aug 2021 16:55:52 -0400
Ken Brown wrote:
On 8/28/2021 11:43 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 13:58:08 +0200
Corinna Vinschen wrote:
On Aug 28 18:41, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 10:43:27
On 8/29/2021 3:24 PM, Chris Roehrig wrote:
I'd be happy to test it out if you can give me some commands to git it and
build it to replace my existing stock Cygwin installation.
(Or it is just the cygwin.dll I'd need to replace?)
My daily backup scripts use a lot of pipes and named pipes.
On 8/29/2021 3:37 PM, Takashi Yano wrote:
On Sun, 29 Aug 2021 11:57:04 -0400
Ken Brown wrote:
On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
On Aug 28 02:21, Takashi Yano
On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
On Fri, 27 Aug 2021 12:00:50 -0400
Ken Brown wrote:
Two years ago I thought I
On Sun, 29 Aug 2021 11:57:04 -0400
Ken Brown wrote:
> On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
> > On Sat, 28 Aug 2021 18:41:02 +0900
> > Takashi Yano wrote:
> >> On Sat, 28 Aug 2021 10:43:27 +0200
> >> Corinna Vinschen wrote:
> >>> On Aug 28 02:21, Takashi Yano via Cygwin wrote:
>
I'd be happy to test it out if you can give me some commands to git it and
build it to replace my existing stock Cygwin installation.
(Or it is just the cygwin.dll I'd need to replace?)
My daily backup scripts use a lot of pipes and named pipes.
-- Chris
On Sun Aug 29 2021, at 8:57 AM, Ken
On 8/29/2021 5:07 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
On Fri, 27 Aug 2021 12:00:50 -0400
Ken Brown wrote:
Two years ago I thought I
On Aug 29 00:43, Takashi Yano via Cygwin wrote:
> On Sat, 28 Aug 2021 13:58:08 +0200
> Corinna Vinschen wrote:
> > On Aug 28 18:41, Takashi Yano via Cygwin wrote:
> > > On Sat, 28 Aug 2021 10:43:27 +0200
> > > Corinna Vinschen wrote:
> > > > On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> > > >
On Sat, 28 Aug 2021 18:41:02 +0900
Takashi Yano wrote:
> On Sat, 28 Aug 2021 10:43:27 +0200
> Corinna Vinschen wrote:
> > On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> > > On Fri, 27 Aug 2021 12:00:50 -0400
> > > Ken Brown wrote:
> > > > Two years ago I thought I needed nt_create to avoid
Hi Ken,
On Sat, 28 Aug 2021 16:55:52 -0400
Ken Brown wrote:
> On 8/28/2021 11:43 AM, Takashi Yano via Cygwin wrote:
> > On Sat, 28 Aug 2021 13:58:08 +0200
> > Corinna Vinschen wrote:
> >> On Aug 28 18:41, Takashi Yano via Cygwin wrote:
> >>> On Sat, 28 Aug 2021 10:43:27 +0200
> >>> Corinna
On 8/28/2021 11:43 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 13:58:08 +0200
Corinna Vinschen wrote:
On Aug 28 18:41, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
On Fri, 27 Aug 2021
On Sat, 28 Aug 2021 13:58:08 +0200
Corinna Vinschen wrote:
> On Aug 28 18:41, Takashi Yano via Cygwin wrote:
> > On Sat, 28 Aug 2021 10:43:27 +0200
> > Corinna Vinschen wrote:
> > > On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> > > > On Fri, 27 Aug 2021 12:00:50 -0400
> > > > Ken Brown wrote:
On 8/28/2021 4:43 AM, Corinna Vinschen via Cygwin wrote:
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
On Fri, 27 Aug 2021 12:00:50 -0400
Ken Brown wrote:
Two years ago I thought I needed nt_create to avoid problems when calling
set_pipe_non_blocking. Are you saying that's not an issue? Is
On Aug 28 18:41, Takashi Yano via Cygwin wrote:
> On Sat, 28 Aug 2021 10:43:27 +0200
> Corinna Vinschen wrote:
> > On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> > > On Fri, 27 Aug 2021 12:00:50 -0400
> > > Ken Brown wrote:
> > > > Two years ago I thought I needed nt_create to avoid problems
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
> On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> > On Fri, 27 Aug 2021 12:00:50 -0400
> > Ken Brown wrote:
> > > Two years ago I thought I needed nt_create to avoid problems when calling
> > > set_pipe_non_blocking. Are you saying
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
> On Fri, 27 Aug 2021 12:00:50 -0400
> Ken Brown wrote:
> > Two years ago I thought I needed nt_create to avoid problems when calling
> > set_pipe_non_blocking. Are you saying that's not an issue? Is
> > set_pipe_non_blocking unnecessary? Is
On Sat, 28 Aug 2021 11:00:24 +0900
Takashi Yano wrote:
> On Sat, 28 Aug 2021 02:21:11 +0900
> Takashi Yano wrote:
>
> > On Fri, 27 Aug 2021 12:00:50 -0400
> > Ken Brown wrote:
> >
> > > On 8/27/2021 7:24 AM, Takashi Yano wrote:
> > > > On Thu, 26 Aug 2021 18:18:29 -0400
> > > > Ken Brown wrote:
On Sat, 28 Aug 2021 02:21:11 +0900
Takashi Yano wrote:
> On Fri, 27 Aug 2021 12:00:50 -0400
> Ken Brown wrote:
>
> > On 8/27/2021 7:24 AM, Takashi Yano wrote:
> > > On Thu, 26 Aug 2021 18:18:29 -0400
> > > Ken Brown wrote:
> > >> On 8/26/2021 11:56 AM, Ken Brown via Cygwin wrote:
> > [...]
> >
On Fri, 27 Aug 2021 12:00:50 -0400
Ken Brown wrote:
> On 8/27/2021 7:24 AM, Takashi Yano wrote:
> > On Thu, 26 Aug 2021 18:18:29 -0400
> > Ken Brown wrote:
> >> On 8/26/2021 11:56 AM, Ken Brown via Cygwin wrote:
> [...]
> >> In case you want to try out my proposed change, I've just rebased the
>
On 8/27/2021 7:24 AM, Takashi Yano wrote:
On Thu, 26 Aug 2021 18:18:29 -0400
Ken Brown wrote:
On 8/26/2021 11:56 AM, Ken Brown via Cygwin wrote:
[...]
In case you want to try out my proposed change, I've just rebased the patches to
the current master and pushed them to a new topic/pipe
;>>>>
> >>>>> I'm trying to figure out why my rsync transfers are so slow (<4 MB/s)
> >>>>> only
> >>>>> when the remote endpoint is Cygwin rsync over sshd (with both a Linux
> >>>>> or
> >>>>> C
and Mac machines and I use rsync to
synchronize various directories between them.
I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only
when the remote endpoint is Cygwin rsync over sshd (with both a Linux or
Cygwin rsync client). In all other scenarios, I get the full 10
various directories between them.
I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only when
the remote endpoint is Cygwin rsync over sshd (with both a Linux or Cygwin rsync
client). In all other scenarios, I get the full 100MB/s as expected from gigabit
ethernet. This has b
On 8/25/2021 4:33 PM, Mario Emmenlauer wrote:
On 25.08.21 19:52, Ken Brown via Cygwin wrote:
A couple years ago I had an idea for changing the pipe implementation to avoid
overlapped I/O:
https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
/pipermail/cygwin-patches/2019q2/009423.html
I never followed up on it. But if you think it might help with this problem, I
could dust it off and try to finish it.
Ken
I'm not familiar enough with the innards of rsync, sshd or cygwin to know how
this would work.
Is it possible to have a new CYGWIN
various directories between them.
> >>
> >> I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only
> >> when the remote endpoint is Cygwin rsync over sshd (with both a Linux or
> >> Cygwin rsync client). In all other scenarios, I get
On 25.08.21 19:52, Ken Brown via Cygwin wrote:
A couple years ago I had an idea for changing the pipe implementation to avoid
overlapped I/O:
https://cygwin.com/pipermail/cygwin-patches/2019q2/009393.html
https://cygwin.com/pipermail/cygwin-patches/2019q2/009423.html
I never followed up
gt;> problem, I could dust it off and try to finish it.
>>
>> Ken
>
> I'm not familiar enough with the innards of rsync, sshd or cygwin to know how
> this would work.
> Is it possible to have a new CYGWIN environment option to switch the pipe
> behaviour witho
9q2/009423.html
>
> I never followed up on it. But if you think it might help with this problem,
> I could dust it off and try to finish it.
>
> Ken
I'm not familiar enough with the innards of rsync, sshd or cygwin to know how
this would work.
Is it possible to have a new CYGWI
MB/s) only when
the remote endpoint is Cygwin rsync over sshd (with both a Linux or Cygwin rsync
client). In all other scenarios, I get the full 100MB/s as expected from gigabit
ethernet. This has been an ongoing problem for me for a couple of years over
several Windows and Cygwin versi
The FILE_FLAG_OVERLAPPED avenue looks promising. I get exactly the same
results as you using 'scp': 4MB/s in either direction (with either remote
endpoint.)
I guess the next step is to install a build environment and build rsync and
sshd ...
On Wed Aug 25 2021, at 4:18 AM, Takashi
It was set to "Programs".Changing it to "Background services" didn't make
a difference.
TCPOptimizer can adjust 2 registry entries that I think are related to that
Windows Setting:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Multimedia\SystemProfile]
endpoint is Cygwin rsync over sshd (with both a Linux or
> Cygwin rsync client). In all other scenarios, I get the full 100MB/s as
> expected from gigabit ethernet. This has been an ongoing problem for me for
> a couple of years over several Windows and Cygwin versions, an
NightStrike via Cygwin wrote:
Older versions of windows had a setting to optimize the OS for either
background services or foreground applications. One of the things this did
was throttle network usage. I don't know if windows 10 has the same setting
though.
Yes, it does. Getting to it is a
nc://$WINHOST/TMP/bigfile.bin /tmp/
# 100MB/s
I was thinking that there might be some Windows Policy that rate-limits some
syscalls for background process, but I also tried:
# ON WINDOWS (Administrator mintty):
cygrunsrv -E cygsshd # exit sshd service
Cygwin rsync over sshd (with both a Linux or
> Cygwin rsync client). In all other scenarios, I get the full 100MB/s as
> expected from gigabit ethernet. This has been an ongoing problem for me
> for a couple of years over several Windows and Cygwin versions, and I'd
> like to try
Linux and Mac machines and I use rsync to
>> synchronize various directories between them.
>> I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only
>> when the remote endpoint is Cygwin rsync over sshd (with both a Linux or
>> Cygwin rsyn
Chris Roehrig wrote:
I have a network of Windows, Linux and Mac machines and I use rsync to
synchronize various directories between them.
I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only when
the remote endpoint is Cygwin rsync over sshd (with both a Linux or Cyg
I have a network of Windows, Linux and Mac machines and I use rsync to
synchronize various directories between them.
I'm trying to figure out why my rsync transfers are so slow (<4 MB/s) only when
the remote endpoint is Cygwin rsync over sshd (with both a Linux or Cygwin
rsync cli
On Aug 6 16:16, ASSI wrote:
> Corinna Vinschen via Cygwin writes:
> >> I found the solution by myself. Installing libcbor-devel package
> >> fixes this error.
> >
> > I just uploaded libfido2-1.5.0-2, which just adds a dependency from
> > libfido2-devel to libcbor-devel.
>
> It would have
Corinna Vinschen via Cygwin writes:
>> I found the solution by myself. Installing libcbor-devel package
>> fixes this error.
>
> I just uploaded libfido2-1.5.0-2, which just adds a dependency from
> libfido2-devel to libcbor-devel.
It would have sufficed to just upload a new hint file…
:-)
On Aug 6 20:14, Takashi Yano via Cygwin wrote:
> On Fri, 6 Aug 2021 11:11:05 +0200
> Corinna Vinschen wrote:
> > On Aug 6 10:55, Takashi Yano via Cygwin wrote:
> > > Hi Corinna,
> > >
> > > On Fri, 6 Aug 2021 01:43:31 +0900
> > > Takashi Yano wrote:
> > > > Hi Corinna,
> > > >
> > > > On Thu,
On Aug 6 21:35, Takashi Yano via Cygwin wrote:
> On Fri, 6 Aug 2021 20:30:58 +0900
> Takashi Yano wrote:
> > On Fri, 6 Aug 2021 01:43:31 +0900
> > Takashi Yano wrote:
> > > In order to look into this problem, I tried to build openssh-8.5p1-1
> > > from source, however it cause the error in
1 - 100 of 2946 matches
Mail list logo
