Den 2024-04-20 14:12, skrev enrique--- via Cygwin:
$ cygrunsrv -I -p /usr/sbin/cron.exe -a -n
cygrunsrv: Trailing commandline arguments not allowed
Try `cygrunsrv --help' for more information.
[snip]
What am I doing wrong?
I found it: Missing service name after "-I".
-Tha
Cron daemon ble stoppet.
$ cygrunsrv -R cron
$ cygrunsrv -I -p /usr/sbin/cron.exe -a -n
cygrunsrv: Trailing commandline arguments not allowed
Try `cygrunsrv --help' for more information.
I also tried a number of other combinations and orders of arguments, all with
similar results.
What
On 4/20/2024 8:12 AM, enrique--- via Cygwin wrote:
Hello,
I am trying to install a service manually in an attempt to understand why
cron-config did not work for me.
So, I did this:
$ net stop cron
Tjenesten Cron daemon stopper .
Tjenesten Cron daemon ble stoppet.
$ cygrunsrv -R cron
Hello,
I am trying to install a service manually in an attempt to understand
why cron-config did not work for me.
So, I did this:
$ net stop cron
Tjenesten Cron daemon stopper .
Tjenesten Cron daemon ble stoppet.
$ cygrunsrv -R cron
$ cygrunsrv -I -p /usr/sbin/cron.exe -a -n
cygrunsrv
On Mon, Feb 6, 2023 at 1:06 PM Corinna Vinschen wrote:
Yeah, quoted paths were not handled at all. I pushed a new version
> 1.64 which contains a patch.
>
Great; thanks!
Bill
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:
ath for cygrunsrv.exe;
> e.g.:
>
> "C:\Program Files\Cygwin\cygrunsrv.exe"
>
> This seems to confuse cygrunsrv -L, though, as it produces no output.
Yeah, quoted paths were not handled at all. I pushed a new version
1.64 which contains a patch.
Thanks,
Corinna
The following packages have been uploaded to the Cygwin distribution:
* cygrunsrv-1.64-1
This release contains a change which is supposed to handle quoted
service application paths to be handeled sanely.
Windows provides a set of functions required to be called by applications
supposed to
e"
This seems to confuse cygrunsrv -L, though, as it produces no output.
Bill
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
On Feb 5 09:15, Doug Henderson via Cygwin wrote:
> Hi,
>
> I tried to run "cygrunsrc -L" in both a regular and elevated shell. In both
> cases I received the same error messages. I do not believe I have any
> cygwin services configured.
>
> $ cy
The following packages have been uploaded to the Cygwin distribution:
* cygrunsrv-1.63-1
Adding two options -T and -X to control timeouts when starting/stopping
the service. Rearranging the package build system.
Windows provides a set of functions required to be called by applications
Greetings, ASSI!
> Andrey Repin via Cygwin writes:
>> The question is a proverbial one: Who's guilty and what to do?
> You have more than one Cygwin installation (cygwin1.dll) and the path is
> different in different environments.
How should I know? Where it is documented?
(Also, it is the same
Andrey Repin via Cygwin writes:
> The question is a proverbial one: Who's guilty and what to do?
You have more than one Cygwin installation (cygwin1.dll) and the path is
different in different environments.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Greetings, All!
When I run cygrunsrv from dash/bash, the list is garbled with braces, while
when I run it from CMD prompt, the list is bare.
For me, this is a regression since before the script
sh -xc "for svc in $( cygrunsrv --list | grep -v cygserver ) cygserver; do net
stop "^&quo
h lists has stopped. What is the
> > final consensus?
> >
> > Should we look for a new updates to the cygwin dll, cygrunsrv, ssh,
> rsync,
> > etc?
>
> All that's needed is an update to the cygwin package. There should be a
> test
> release coming very soo
Looks like the lively discussion on both lists has stopped. What is the
final consensus?
Should we look for a new updates to the cygwin dll, cygrunsrv, ssh, rsync,
etc?
All that's needed is an update to the cygwin package. There should be a test
release coming very soon, possibly tomorrow
What is the
final consensus?
Should we look for a new updates to the cygwin dll, cygrunsrv, ssh, rsync,
etc?
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info:
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
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.
(However, I built it against the stock /usr/include, not the current branch...)
I first needed to 'make /proc/libprocps.la', and there was an
I've found you must also copy the matching cygwin-console-helper.exe
for everything to work correctly!
On 2021-08-31 14:23, Chris Roehrig wrote:
I did a 'git pull' of the latest topic/pipe and rebuilt and I now do indeed get
100MB/s transfers using both rsync and scp (without pipe_byte).
(It t
I did a 'git pull' of the latest topic/pipe and rebuilt and I now do indeed get
100MB/s transfers using both rsync and scp (without pipe_byte).
(It turns out last time I forgot 'make install' -- Doh!)
I still get the procps error however.
On Tue Aug 31 2021, at 12:53 PM, Chris Roehrig wrote:
Thanks, I did some more tests:
scp also shows no improvement with topic/pipe.I tried running
cygsshd with CYGWIN=pipe_byte as well as empty (in the registry
HKLM/SYSTEM/CurrentControlSet/Services/cygsshd/Parameters/Environment/), using
net stop cygsshd + net start cygsshd to restart
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
re
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 the main
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.
and Cygwin versions, and I'd
> >>>>> like to try to fix it.
> >>>>>
> >>>>> If I run rsync --daemon --no-detach under mintty in the foreground on
> >>>>> the
> >>>>> remote Windows endpoint, I get th
e full 100 MB/s transfers, so it seems
like it has something to do with rsync.exe running in the background under
the cygrunsrv+sshd service (which was installed normally using
ssh-host-config).
If I do:
pv /dev/zero | ssh $WINHOST "cat > /dev/null"
or even
pv /dev/urand
mething to do with rsync.exe running in the background under the
cygrunsrv+sshd service (which was installed normally using ssh-host-config).
If I do:
pv /dev/zero | ssh $WINHOST "cat > /dev/null"
or even
pv /dev/urandom | ssh $WINHOST md5sum
I also get the full
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
On 8/25/2021 2:18 PM, Chris Roehrig wrote:
On Wed Aug 25 2021, at 10:52 AM, 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/pipermai
-no-detach under mintty in the foreground on the
> >> remote Windows endpoint, I get the full 100 MB/s transfers, so it seems
> >> like it has something to do with rsync.exe running in the background under
> >> the cygrunsrv+sshd service (which was installed normally using
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
d Cygwin versions, and I'd
>>>> like to try to fix it.
>>>>
>>>> If I run rsync --daemon --no-detach under mintty in the foreground on the
>>>> remote Windows endpoint, I get the full 100 MB/s transfers, so it seems
>>>> like it has so
and I'd
>>> like to try to fix it.
>>>
>>> If I run rsync --daemon --no-detach under mintty in the foreground on the
>>> remote Windows endpoint, I get the full 100 MB/s transfers, so it seems
>>> like it has something to do with rsync.exe running
ons, and I'd like to try to fix it.
If I run rsync --daemon --no-detach under mintty in the foreground on the
remote Windows endpoint, I get the full 100 MB/s transfers, so it seems like
it has something to do with rsync.exe running in the background under the
cygrunsrv+sshd service (which
> a couple of years over several Windows and Cygwin versions, and I'd like to
>> try to fix it.
>>
>> If I run rsync --daemon --no-detach under mintty in the foreground on the
>> remote Windows endpoint, I get the full 100 MB/s transfers, so it seems
>>
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
and I'd like to
> try to fix it.
>
> If I run rsync --daemon --no-detach under mintty in the foreground on the
> remote Windows endpoint, I get the full 100 MB/s transfers, so it seems like
> it has something to do with rsync.exe running in the background under the
> cygruns
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
ike to try to fix it.
>
> If I run rsync --daemon --no-detach under mintty in the foreground on the
> remote Windows endpoint, I get the full 100 MB/s transfers, so it seems
> like it has something to do with rsync.exe running in the background under
> the cygrunsrv+sshd service (which
detach under mintty in the foreground on the
>> remote Windows endpoint, I get the full 100 MB/s transfers, so it seems
>> like it has something to do with rsync.exe running in the background under
>> the cygrunsrv+sshd service (which was installed normally using
>> ss
mintty in the foreground on the
remote Windows endpoint, I get the full 100 MB/s transfers, so it seems like
it has something to do with rsync.exe running in the background under the
cygrunsrv+sshd service (which was installed normally using ssh-host-config).
If I do:
pv /dev/zero | ssh
ground on the
remote Windows endpoint, I get the full 100 MB/s transfers, so it seems like
it has something to do with rsync.exe running in the background under the
cygrunsrv+sshd service (which was installed normally using ssh-host-config).
If I do:
pv /dev/zero | ssh $WINHOST "cat &g
n most decent
> mailers.
>
> Finally, when you do need the pre-shutdown option, you can specify it with
> cygrunsrv directly (-O, --preshutdown)
> -- no need to deal with any manual registry changes.
That is a service initial configuration option (stored in the registry) which
th
1 - 100 of 829 matches
Mail list logo
