TL;DR
Cygwin/X over ssh = unusable performance
Cygwin/X over XDMCP = good performance
Details
Cygwin/Windows 11: AMD Ryzen 9 7940HS, 32GB, 2.5GB LAN
Linux/Debian 12: Intel i5-1135G7, 16GB, 2.5GB LAN
I use Cygwin/X as an X server to work with Eclipse on a Debian 12 system
on the local 2.5Gbp
enance time without losing protection to
boot.)
As I said, with Trend and other badly-written AV services, simply
excluding an executable or directory does not prevent the slow down. In
some cases even 'disabling' the AV using its UI does not either,
probably because this doesn't ac
Hi,
For me not use AV or disable parts is not an option...
Then, if AV is inspecting the CreateProcess, these processes can be known
the path of these process?
Ex, I launch grep. One AV process can discern the path of these process, or
it is impossible to find out if the executable is inside of
On 10/04/2024 11:34, Christian Franke via Cygwin wrote:
J M via Cygwin wrote:
...
Specifically for this problem, I have investigated the problem and can be
related to pipes and antivirus.
Specifically
while true
do
echo ABC | grep AAA
done
It makes the cpu of that antivirus go up.
This is a
-c
...
65 1712742865 <== Windows Defender off
66 1712742866
66 1712742867
64 1712742868
61 1712742869
51 1712742870 <== Windows Defender turned on
51 1712742871
49 1712742872
45 1712742873
53 1712742874
54 1712742875
...
The above could even s
win64 and perhaps those paths of
those pipes are having effects in that other software.
By now this...
Regards
El lun., 8 abr. 2024 21:48, Adam Dinwoodie escribió:
> On Fri, 5 Apr 2024 at 16:19, J M via Cygwin wrote:
> >
> > Hi,
> >
> > I'm seeing that Cyg
On Fri, 5 Apr 2024 at 16:19, J M via Cygwin wrote:
>
> Hi,
>
> I'm seeing that Cygwin is a bit slow, directly and after comparing to
> simple ubuntu virtual machines by example.
>
> Specifically:
>
> - Copy and paste texts in vim, I see clearly the slow in paste
On Fri, Apr 5, 2024 at 11:18 AM J M wrote:
>
> Hi,
>
> I'm seeing that Cygwin is a bit slow, directly and after comparing to
> simple ubuntu virtual machines by example.
>
> Specifically:
>
> - Copy and paste texts in vim, I see clearly the slow in paste.
I don&
On 2024-04-05 09:21, J M via Cygwin wrote:
I added, sed and grex x60 to x80, no software running and no antivirus.
El vie., 5 abr. 2024 17:18, J M escribió:
I'm seeing that Cygwin is a bit slow, directly and after comparing to
simple ubuntu virtual machines by example.
Specifically:
- Cop
I added, sed and grex x60 to x80, no software running and no antivirus.
Regards
El vie., 5 abr. 2024 17:18, J M escribió:
> Hi,
>
> I'm seeing that Cygwin is a bit slow, directly and after comparing to
> simple ubuntu virtual machines by example.
>
> Specifically:
>
&
Hi,
I'm seeing that Cygwin is a bit slow, directly and after comparing to
simple ubuntu virtual machines by example.
Specifically:
- Copy and paste texts in vim, I see clearly the slow in paste.
- Using sed and/or grep that count approx. between 6x and 8x respect to
virtual machine s
Greetings, Derek Pagel!
> I've been having intermittent slowness with Cygwin commands even after
> installing Cygserver. It has helped reduce the frequency of occurrences of
> slowness, but it hasn't gotten rid of them completely. I recently had a
> 'mv.exe' that w
I have been able to replicate Cygwin commands hanging on a Windows 2019 server
by running a program that loops through cp, mv, chmod and rm 100 times every 15
mins. I'm also running each of those Cygwin commands through a Microsoft
utility that reports which specific Windows API a thread has cal
> > Milliseconds : 552
> > Ticks : 225529747
> > TotalDays : 0.000261029799768519
> > TotalHours: 0.0062647151944
> > TotalMinutes : 0.37588291167
> > TotalSeconds : 22.5529747
> > TotalMilliseconds : 22552.9747
> &
east the output from:
$ uname -srvmo
so we can see your Cygwin and Windows releases.
Try running the same slow commands under strace e.g.
$ strace -o cp-strace.out cp ...
and attach those outputs and
$ cygcheck -hrsv > cygcheck.out
as text, and someone may be abl
We are seeing more instances of application slowness due to Cygwin programs
like 'cp' and 'mv' being executed. The files being 'cp' or 'mv' are not very
big and they stay on the same server. We have installed Cygserver which has
improved things a little bit but there are still many cases of slow
: 22
> > Milliseconds : 552
> > Ticks : 225529747
> > TotalDays : 0.000261029799768519
> > TotalHours: 0.0062647151944
> > TotalMinutes : 0.37588291167
> > TotalSeconds : 22.5529747
> > TotalMilliseconds : 22
TotalMilliseconds : 22552.9747
I have also tried this with 3.4.7 - same issue.
Using 3.1.7 there is no slow down. I haven't tried any versions between
3.1.7 and 3.4.7 yet, but I can do that.
I'm running Windows 10 21H2 (19044.3086).
https://cygwin.com/faq.html#faq.using.startup-slow
Probab
- same issue.
Using 3.1.7 there is no slow down. I haven't tried any versions between
3.1.7 and 3.4.7 yet, but I can do that.
I'm running Windows 10 21H2 (19044.3086).
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Doc
I've been having intermittent slowness with Cygwin commands even after
installing Cygserver. It has helped reduce the frequency of occurrences of
slowness, but it hasn't gotten rid of them completely. I recently had a
'mv.exe' that was slow, so I ran a few commands to get
Stop using ` already. Or at the very least use it properly.
Either
icacls `cygpath -m interchange.20230418091901`
or
icacls "$(cygpath -m interchange.20230418091901)"
Not to mention, you don't need to cygpath the file in current directory.
Just
icacls "interchange.20230418091901.tmp"
should su
Greetings, Derek Pagel!
> The icalcs command doesn’t work on either and I haven’t been able to get it
> to work elsewhere either.
> D:\lsenv\law\lsapps\edi\work>icacls "`cygpath -m interchange.20230418091901"
> `cygpath -m interchange.20230418091901: The system cannot find the file
> specified
Looks like the ACL has not been written, so the incoming ACEs are still being
looked up (and/or maybe inherited)?
Where was that file moved from and what were the files' permissions and ACLs
before and after?
Anyone know what execute permission *a* means? -rwxrwxrwa [above]
On 2023-04-14 08:10, Derek Pagel via Cygwin wrote:
Could be long ACL lists with many unique ACEs that need looked up on AD,
and/or slow ADCs, and/or slow AV, and/or slow net:
for each file show the outputs of
$ ls -dl $f
$ getfacl $f
$ icacls "`cygpath -m $f`"
Could be long ACL lists with many unique ACEs that need looked up on AD, and/or
slow ADCs, and/or slow AV, and/or slow net:
for each file show the outputs of
$ ls -dl $f
$ getfacl $f
$ icacls "`cygpath -m $f`"
and also attach as text, the output from strace
lists with many unique ACEs that need looked up on AD, and/or
slow ADCs, and/or slow AV, and/or slow net:
for each file show the outputs of
$ ls -dl $f
$ getfacl $f
$ icacls "`cygpath -m $f`"
and also attach as text, the output from strace on the cp command, as it
how big are these files and from where to where are you copying them ?
AV interference ?
The files being copied are not very big at all and they're just being copied
from one directory to another on the same server.
--
Problem reports: https://cygwin.com/problems.html
FAQ:
On Tue, Apr 11, 2023 at 10:08 PM Derek Pagel via Cygwin wrote:
>
> I've been seeing an issue where Cygwin commands sometimes take a while to
> complete, or they will not complete at all and will have to be manually
> killed through task manager. I installed Cygserver and that helped to lessen
>
I've been seeing an issue where Cygwin commands sometimes take a while to
complete, or they will not complete at all and will have to be manually killed
through task manager. I installed Cygserver and that helped to lessen the
number of times that the issue happens but it didn't get rid of it. I
In the past we've noticed that Cygwin commands are intermittently slow and can
take about 42 seconds to complete on Windows. We then installed Cygserver to
try and avoid the slowness and it has worked for the most part. However, we do
still have instances where we've noticed the co
Eliot Moss via Cygwin wrote:
On 1/15/2023 3:38 AM, Christian Franke via Cygwin wrote:
Eliot Moss via Cygwin wrote:
I have a separate drive mounted this way:
d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0
One thing I use it for is to store backup files. These tend to be 2 Gb
chunks,
On Sun, Jan 15, 2023 at 12:05:10PM +1100, Eliot Moss via Cygwin wrote:
> On 1/15/2023 3:38 AM, Christian Franke via Cygwin wrote:
> > Eliot Moss via Cygwin wrote:
> > > I have a separate drive mounted this way:
> > >
> > > d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0
> > >
> > > One th
On 1/15/2023 3:38 AM, Christian Franke via Cygwin wrote:
Eliot Moss via Cygwin wrote:
I have a separate drive mounted this way:
d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0
One thing I use it for is to store backup files. These tend to be 2 Gb
chunks, and there can be hundreds of t
Eliot Moss via Cygwin wrote:
I have a separate drive mounted this way:
d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0
One thing I use it for is to store backup files. These tend to be 2 Gb
chunks, and there can be hundreds of them in the backup directory.
(The drive
is 5Tb.) The Wi
movable (an external WD MyPassport hard drive).
I *suspect* this will be an issue with `ls` querying some file
metadata that are relatively slow to get out of an NTFS system, to
provide a similar interface to native *nix systems, where Windows' tools
unsurprisigly care more about the sort
Dear Cygwin'ers -
I have a separate drive mounted this way:
d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0
One thing I use it for is to store backup files. These tend to be 2 Gb
chunks, and there can be hundreds of them in the backup directory. (The drive
is 5Tb.) The Windows Disk M
est if
the 3.2 version is the culprit or not.
I also upgraded from windows 10 to windows 11 on the PC experiencing the
slow start issue, and that didn't have any effect on the problem.
Search the FAQ for slow e.g.
https://cygwin.com/faq/faq.html#faq.using.startup-slow
This sounds like
o upgraded from windows 10 to windows 11 on the PC experiencing the
slow start issue, and that didn't have any effect on the problem.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubsc
On 2022/01/31 13:36, Adam Dinwoodie wrote:
Could it be that the first 'mv' triggered an anti-virus read of the file since
perhaps it detects it as a new/changed file?
But if so, would 'mv' (under Task Manager) be showing the 100+ MB/s disk
activity?
That definitely seems plausible; the
Greetings, cyg...@kosowsky.org!
> I literally am typing something like:
> mv foo bar
> In Linux, that just edits the file system table & inode...
> UPDATE...
> I just tried a second 'mv' and it was near instantaneous.
> (and similarly with subsequent renaming of the same file)
> So perhaps not
On Mon, Jan 31, 2022 at 10:17:59AM -0500, cyg...@kosowsky.org wrote:
> Eliot Moss wrote at about 09:59:17 -0500 on Monday, January 31, 2022:
> > On 1/31/2022 9:52 AM, cyg...@kosowsky.org wrote:
> > > I tried renaming some very large files (20-40 GB) using:
> > > mv
> > > without changi
>
> In my case the directory (where I renamed the file) is on my C-drive.
>
If the file is currently open for access, the move can turn out to be a copy,
actually.
Check open files to make sure whatever you are moving is not being opened /
accessed from any other program.
Anton Lavrentiev
Con
ile being really moved (aka copied) rather than
> >> just renamed?
> >
> > The two places are probably on different volumes (loosely, different
> > disks). That requires a physical move, even under Linux. Your
> > volumes seem a bit slow to access - is one perh
Eliot Moss wrote at about 09:59:17 -0500 on Monday, January 31, 2022:
> On 1/31/2022 9:52 AM, cyg...@kosowsky.org wrote:
> > I tried renaming some very large files (20-40 GB) using:
> > mv
> > without changing the directory of course.
> >
> > The process took about 10-20 minutes wi
there something about such large 'renaming' that actually
results in the file being really moved (aka copied) rather than
just renamed?
The two places are probably on different volumes (loosely, different
disks). That requires a physical move, even under Linux. Your
volumes seem a b
ere something about such large 'renaming' that actually results
> in the file being really moved (aka copied) rather than just renamed?
The two places are probably on different volumes (loosely, different disks).
That requires a physical move, even under Linux. Your volumes seem a bit slo
I tried renaming some very large files (20-40 GB) using:
mv
without changing the directory of course.
The process took about 10-20 minutes with Task Manager showing disk
activity of 100+ MB/s.
Is there something about such large 'renaming' that actually results
in the file being really moved
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
y, put your Cygwin installation on SSD and exclude
the Cygwin root (and local mirror directory) from real-time virus scans.
I do monthly updates on slow machines (CPU is a 1.8GHz IvyBridge
Celeron) and that takes around two to five minutes depending on how
large the update is in any given m
ygwin Setup upgrades can take as long as Windows Update installing the
latest patches.
Some of my approaches, suggestions, and participation here are coloured
by those limitations (also by expensive, slow, uncompetitive networks).]
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Th
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
1 - 100 of 1232 matches
Mail list logo
