-R" for 'other_user', as suggested by the subject of
the post, fixed the problems for me.
It looks like sshd isn't handling a login failure properly.
Andy.
On Tue, Sep 3, 2024 at 7:57 PM Jim McNamara via Cygwin
wrote:
>
> >>This looks like a bug. Can anyone hel
>>This looks like a bug. Can anyone help? Is there a work-around?
Hi Andy,
There was some chatter the last week or 2 on someone trying to get ssh to work.
At the archive mailing list, you can read and see if that answers any of it.
I thought the gist of it is that a cipher is being swapped out
Hi,
I've installed Cygwin and OpenSSH on a Windows machine and set up the
sshd daemon as follows:
mkpassd -l > /etc/passwd
mkgroup -l > /etc/group
chmod +r /etc/passwd /etc/group
chmod 777 /var
ssh-host-config
cygrunsrv -S cygsshd
SSH now works for user account that set up SSHD, ie
On Wed, 31 Jul 2024, Brian Inglis via Cygwin wrote:
> On 2024-07-31 13:16, Jim McNamara via Cygwin wrote:
> > Hi-
> >
> > I am running into a little difficulty with openssh can you please assist ?
> >
> > thanks jim
> >
> > ./cygrunsrv --install
On Wed, 31 Jul 2024 19:16:26 +
Jim McNamara wrote:
> I am running into a little difficulty with openssh can you please assist ?
>
> thanks jim
>
> ./cygrunsrv --install sshd -d "Cygwin SSHD" -p /usr/bin/sshd -a "-D"
> ./cygrunsrv: Given path doe
On 2024-07-31 13:16, Jim McNamara via Cygwin wrote:
Hi-
I am running into a little difficulty with openssh can you please assist ?
thanks jim
./cygrunsrv --install sshd -d "Cygwin SSHD" -p /usr/bin/sshd -a "-D"
./cygrunsrv: Given path doesn't point to a valid ex
On 31 Jul 2024, at 21:16, Jim McNamara via Cygwin wrote:
> I am running into a little difficulty with openssh can you please assist ?
>
> thanks jim
>
> ./cygrunsrv --install sshd -d "Cygwin SSHD" -p /usr/bin/sshd -a "-D"
> ./cygrunsrv: Given path doesn&#
Hi-
I am running into a little difficulty with openssh can you please assist ?
thanks jim
./cygrunsrv --install sshd -d "Cygwin SSHD" -p /usr/bin/sshd -a "-D"
./cygrunsrv: Given path doesn't point to a valid executable
Try `./cygrunsrv --help' for more informatio
*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://
Ernie 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 crea
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
'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
>>> cyg_serv 255 254 ? Feb 1 /usr/sbin/
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
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
win 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?
Su
want to look 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 : /us
$ 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?
Suggestions for something else to try and/
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
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 a
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 li
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 o
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 c
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 init
> >
> > 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 last
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 you
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 h
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 DLL
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 DLL
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 r
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 could
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 could
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 Cyg
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, Ken
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 wr
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 Cyg
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
3ca80b3
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 pr
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 s
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
set
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 o
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 pa
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,
MAP
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, page
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,
MAP
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 == MAP_FA
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 appea
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 ma
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 fro
[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 packag
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 branch.
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 C
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 c
; -- Chris
>>
>>
>>
>> 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
>>>> Monda
get
the procps error using the latest stock 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
86_64.
>
> -- Chris
>
>
>
> 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):
>
/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: procp
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: p
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 usin
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:
> O
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 10:43
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 Vinsche
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.
It's
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 vi
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 Br
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 probl
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 Vinsche
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 12:00
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 whe
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 that
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 that
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 branch.
;>>>
> >>>>> 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
> >>>>&
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 fu
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
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
https://cygwin.com/pipermail/cygwin-p
/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 C
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 ge
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
is
>> 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
> behav
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
<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 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 A
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]
"NetworkT
mote 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,
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 pa
a rsync://$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
1 - 100 of 3025 matches
Mail list logo
