On Jan 24, 2015, at 1:44 PM, Sunny wrote:
> Christopher Faylor please cygwin.com> writes:
>
>>
>> On Fri, Sep 07, 2007 at 09:57:13AM -0500,
> Jonathan Hurd wrote:
>>> Sorry to bring back this old thread back.
> Is there anyone that can explain
>>> a fix for this problem. I've only been
>
Christopher Faylor cygwin.com> writes:
>
> On Fri, Sep 07, 2007 at 09:57:13AM -0500,
Jonathan Hurd wrote:
> > Sorry to bring back this old thread back.
Is there anyone that can explain
> > a fix for this problem. I've only been
using rsync/cygwin/on ssh for about
> > 3 weeks, so please expl
Jonathan Hurd wrote:
Christopher Faylor wrote:
On Fri, Sep 07, 2007 at 09:57:13AM -0500, Jonathan Hurd wrote:
Sorry to bring back this old thread back. Is there anyone that can
explain a fix for this problem. I've only been using rsync/cygwin/on
ssh for about 3 weeks, so please explain in dumm
It just doesn't make sense how this can work perfectly for about 2
weeks, and then out of nowhere all sync's start to hang with transfer
over a certain amount.
Christopher Faylor wrote:
On Fri, Sep 07, 2007 at 09:57:13AM -0500, Jonathan Hurd wrote:
Sorry to bring back this old thread back. Is
On Fri, Sep 07, 2007 at 09:57:13AM -0500, Jonathan Hurd wrote:
> Sorry to bring back this old thread back. Is there anyone that can explain
> a fix for this problem. I've only been using rsync/cygwin/on ssh for about
> 3 weeks, so please explain in dummy terms.
It's easy to explain - There is no
Sorry to bring back this old thread back. Is there anyone that can
explain a fix for this problem. I've only been using rsync/cygwin/on ssh
for about 3 weeks, so please explain in dummy terms.
It's the exact same problem mentioned here:
http://cygwin.com/ml/cygwin/2006-04/msg00792.html
--
On Jul 7 09:58, Darryl Miles wrote:
> Corinna Vinschen wrote:
> >On Jul 7 08:43, Darryl Miles wrote:
> >>What was the reason the existing code in CVS for select.cc was disabled?
> >>
> >>Maybe it would help to better understand the reasons/cases where the
> >>disabled code failed.
> >
> >Hangs w
Corinna Vinschen wrote:
On Jul 7 08:43, Darryl Miles wrote:
What was the reason the existing code in CVS for select.cc was disabled?
Maybe it would help to better understand the reasons/cases where the
disabled code failed.
Hangs with native Windows applications, AFAIR.
I take this to mea
On Jul 7 08:43, Darryl Miles wrote:
> What was the reason the existing code in CVS for select.cc was disabled?
>
> Maybe it would help to better understand the reasons/cases where the
> disabled code failed.
Hangs with native Windows applications, AFAIR.
Corinna
--
Corinna Vinschen
Lev Bishop wrote:
On 7/7/06, Darryl Miles wrote:
Dave Korn wrote:
> On 07 July 2006 01:31, Darryl Miles wrote:
The underlying socket is still being used in blocking mode.
Socket?? What is this socket?
Sorry s/socket/pipe/.
Which means
when we write write 1024 bytes of data but only one PI
On 7/7/06, Darryl Miles wrote:
Dave Korn wrote:
> On 07 July 2006 01:31, Darryl Miles wrote:
>> Maybe you are in a better position to share more insight into the
>> situation (specifically about the use of NtQueryInformationFile in
>> addressing the writability semantics of the POSIX select/poll/
Dave Korn wrote:
On 07 July 2006 01:31, Darryl Miles wrote:
Maybe you are in a better position to share more insight into the
situation (specifically about the use of NtQueryInformationFile in
addressing the writability semantics of the POSIX select/poll/write
event system).
I think you shou
On 07 July 2006 01:31, Darryl Miles wrote:
> Dave Korn wrote:
>> On 06 July 2006 23:02, Darryl Miles wrote:
>>> However according to MSDN this function is undocumented.
>>
>> No, it's documented in the DDK these days.
>>
>>
http://msdn.microsoft.com/library/en-us/Kernel_r/hh/Kernel_r/k111_822a
Dave Korn wrote:
On 06 July 2006 23:02, Darryl Miles wrote:
However according to MSDN this function is undocumented.
No, it's documented in the DDK these days.
http://msdn.microsoft.com/library/en-us/Kernel_r/hh/Kernel_r/k111_822ab812-a644-4574-8d89-c4ebf5b17ea5.xml.asp?frame=true
(ZwQuer
On 06 July 2006 23:02, Darryl Miles wrote:
> Christopher Faylor wrote:
>> On Sat, Jul 01, 2006 at 11:05:24AM -0400, Christopher Faylor wrote:
>> Since I'm not getting any nibbles when I talk about "the person
>> responsible" here, I guess he must be long gone by now.
>>
>> So, his pipe code, whic
Christopher Faylor wrote:
On Sat, Jul 01, 2006 at 11:05:24AM -0400, Christopher Faylor wrote:
Since I'm not getting any nibbles when I talk about "the person
responsible" here, I guess he must be long gone by now.
So, his pipe code, which seemed to be based on correct concepts, is
basically up f
On Sat, Jul 01, 2006 at 11:05:24AM -0400, Christopher Faylor wrote:
>You are misunderstanding me. There is code in cygwin which is designed
>to work around the problem of select() not working correctly when it is
>used to test the write side of pipes. It is currently turned off
>because it wasn't
On Sat, Jul 01, 2006 at 03:11:48PM +0100, Darryl Miles wrote:
>Christopher Faylor wrote:
>>I just want to be clear here. I really do want to be convinced that
>>the current implementation in cygwin can't be fixed before we scrap
>>that and implement something new.
>
>Yes I intend to "convince" the
Christopher Faylor wrote:
I just want to be clear here. I really do want to be convinced that the
current implementation in cygwin can't be fixed before we scrap that and
implement something new.
Yes I intend to "convince" the list of my findings.
I have simple cut down unix code that works o
mwoehlke wrote:
> Um... probably? Did you try looking at them? There is an
> InterlockedExchangeAdd (I think that's the right name... anyway, you
> feed it a pointer and a constant, and you get back the previous value).
> At any rate, anything Linux can do in assembly, Windows can also do,
> also
On Fri, Jun 30, 2006 at 04:12:11PM +0100, Darryl Miles wrote:
>Darryl Miles wrote:
>>There maybe other ways to deal with that write() but as far as I
>>understand the NT kernel does not provide a true non-blocking mechanism
>>to work from with pipes. This is where you can offer to the kernel the
Darryl Miles wrote:
mwoehlke wrote:
Darryl Miles wrote:
[snip]
* The outstanding byte count needs to be protected by a mutex.
Are you familiar with the Interlocked* family of functions? Depending
on what exactly you need to do with the value, a mutex may be
unnecessary.
Do these function
mwoehlke wrote:
Darryl Miles wrote:
[snip]
* The outstanding byte count needs to be protected by a mutex.
Are you familiar with the Interlocked* family of functions? Depending on
what exactly you need to do with the value, a mutex may be unnecessary.
Do these function perform buslock prefi
Darryl Miles wrote:
[snip]
* The outstanding byte count needs to be protected by a mutex.
Are you familiar with the Interlocked* family of functions? Depending on
what exactly you need to do with the value, a mutex may be unnecessary.
Fascinating discussion, but over my head without taking
Darryl Miles wrote:
There maybe other ways to deal with that write() but as far as I
understand the NT kernel does not provide a true non-blocking mechanism
to work from with pipes. This is where you can offer to the kernel the
data and if the buffers are full the kernel will reject the data w
Lev Bishop wrote:
On 6/28/06, Darryl Miles wrote:
See how-to-debug-cygwin.txt
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-to-debug-cygwin.txt?rev=1.12&content-type=text/x-cvsweb-markup&cvsroot=src
Thanks for your pointers. Everything I'm wanting to get started is
already cover
On Jun 29 22:01, Lev Bishop wrote:
> On 6/29/06, Darryl Miles wrote:
>
> >I also think from reading through the WIN32 API that I either get
> >blocking IO or overlapped IO, where overlapped is non-blocking with
> >async I/O completion signaling. This mode isn't directly compatible
> >with non-blo
On Thu, Jun 29, 2006 at 11:36:41PM -0400, Lev Bishop wrote:
>On 6/29/06, Christopher Faylor wrote:
>>The idea of using threads for pipe writing has been bounced around for
>>a long time. It doesn't solve the select problem if there are multiple
>>processes writing to one pipe. That is not a compl
On 6/29/06, Christopher Faylor wrote:
For the record, I'm not wild about scrapping the existing (but currently
turned off) code in cygwin that is supposed to fix this. Using the NT
api was supposed to allow us to do what we wanted with no half-measures.
I'd rather see someone finish that, or at
On 6/29/06, Darryl Miles wrote:
I also think from reading through the WIN32 API that I either get
blocking IO or overlapped IO, where overlapped is non-blocking with
async I/O completion signaling. This mode isn't directly compatible
with non-blocking of Unix the way I see it as the data is sti
On 6/28/06, Darryl Miles wrote:
How do I pull down ssh/rsync/cygwin.dll and build in a way that I can
see the problem ?
For ssh and rsync sources, use cygwin setup.exe. For cygwin.dll see
http://cygwin.com/contrib.html
Especially note the requirement to sign a copyright release, if you
want yo
On Fri, Jun 30, 2006 at 12:46:50AM +0100, Darryl Miles wrote:
>Darryl Miles wrote:
>>Linux<>CGYWIN where linux is client and pulling data down hangs very
>>quickly after connection and getting the first large file (> 256Kb) to
>>download.
>
>The problem goes away if the WIN32 side is Win2003. It
Darryl Miles wrote:
Linux<>CGYWIN where linux is client and pulling data down hangs very
quickly after connection and getting the first large file (> 256Kb) to
download.
The problem goes away if the WIN32 side is Win2003. Its only Win2k
which I am seeing problems with.
I have looked thro
Sorry to rake this thread from a few months ago.
Corinna Vinschen wrote (on 27 Apr 2006 ) :
The "rsync hangs" problem is not actually a new one. We had
these reports already ages ago. However, *nobody* so far having that
problem seem to be willing to actually debug this problem and track it
On 01 May 2006 15:58, Brian Ford wrote:
> On Thu, 27 Apr 2006, Dave Korn wrote:
>
>> On 26 April 2006 20:34, Steven Hartland wrote:
>>
>>> Interestingly if I try to get a thread dump using
>>> sysinternals process explorer the rsync process goes
>>> mad using all available cpu.
>>
>> That's a
Corinna Vinschen wrote:
freebsd1> ssh cygwin1
cygwin1> echo "1" > /tmp/test.txt
cygwin1> cat /tmp/test.txt
1
cygwin1> exit
freebsd1> ssh cygwin1 "cat /tmp/test.txt"
*** no output ***
Looks like its just not flushing the output at someone point in the
reworked code.
I just tried it a couple of
This is really a tricky problem. What I could do to circumvent this at
least for connections over ssh is to upload an OpenSSH test version
which uses socketpairs instead of pipes for the local connection to the
applications. This avoids using pipes which are the culprit here,
This thread's
On Apr 29 01:53, Steven Hartland wrote:
> Steven Hartland wrote:
> >Good news this does fix the issue. I've just successfully done
> >an rsync of ~1G ( 1700 files ) with no problem at all.
> >
> >Also note that due to the existing performance issues in ssh ( I've
> >still not had chance to dig more
Steven Hartland wrote:
Good news this does fix the issue. I've just successfully done
an rsync of ~1G ( 1700 files ) with no problem at all.
Also note that due to the existing performance issues in ssh ( I've
still not had chance to dig more about that sorry ) there is NO
noticable slowdown when
On Fri, Apr 28, 2006 at 06:25:35AM -0400, Brett Serkez wrote:
>I've noticed multiple postings indicating issues with pipes. Wouldn't
>it be better to track this down, it would likely fix multiple
>problems.
I think you meant to post this to the cygwin-facile-advice mailing list.
cgf
--
Unsubscr
Corinna Vinschen wrote:
It works fine for me with the latest snapshot. I tried Peter's
example with 1000 files and rsync over ssh works like a charm for me.
Sigh.
This is really a tricky problem. What I could do to circumvent this
at least for connections over ssh is to upload an OpenSSH tes
- Original Message -
From: "Corinna Vinschen" <[EMAIL PROTECTED]>
Damn (sorry).
It works fine for me with the latest snapshot. I tried Peter's example
with 1000 files and rsync over ssh works like a charm for me. Sigh.
This is really a tricky problem. What I could do to circumvent
On Apr 28 06:25, Brett Serkez wrote:
> >This is really a tricky problem. What I could do to circumvent this at
> >least for connections over ssh is to upload an OpenSSH test version
> >which uses socketpairs instead of pipes for the local connection to the
> >applications. This avoids using pipes
This is really a tricky problem. What I could do to circumvent this at
least for connections over ssh is to upload an OpenSSH test version
which uses socketpairs instead of pipes for the local connection to the
applications. This avoids using pipes which are the culprit here,
apparently.I wo
On Apr 27 20:15, Steven Hartland wrote:
> - Original Message -
> From: "Christopher Faylor" <[EMAIL PROTECTED]>
>
> > "Search for cygwin1.dll using the Windows Start->Find/Search facility
> > and delete all but the most recent version. The most recent version
> > *should* reside in x:\c
- Original Message -
From: "Christopher Faylor" <[EMAIL PROTECTED]>
"Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version
*should* reside in x:\cygwin\bin, where 'x' is the drive on which you have
On Thu, Apr 27, 2006 at 07:59:05PM +0100, Steven Hartland wrote:
>- Original Message -
>From: "Christopher Faylor"
>>>Would it help the base rsync case do you think Corinna? Should I try
>>>the snapshot here to check, if so what's the snapshot indent and where's
>>>the best place to obtain
- Original Message -
From: "Christopher Faylor"
Would it help the base rsync case do you think Corinna? Should I try
the snapshot here to check, if so what's the snapshot indent and where's
the best place to obtain it from, not used snapshots before but if
it would help you guys test wort
On Thu, Apr 27, 2006 at 07:41:17PM +0100, Steven Hartland wrote:
>- Original Message -
>From: "Corinna Vinschen"
>
>>>maybe, the amount of files has to be increased in order to provoke the
>>>error. I have run my script with only 100 instead of 300 files and it
>>>works. Maybe, you can g
- Original Message -
From: "Corinna Vinschen" <[EMAIL PROTECTED]>
maybe, the amount of files has to be increased in order to provoke the
error. I have run my script with only 100 instead of 300 files and it
works. Maybe, you can give it a try.
I did and I could reproduce it. Thanks
On Thu, Apr 27, 2006 at 08:04:50PM +0200, Peter Keitler wrote:
>corinna wrote:
>>On Apr 27 11:21, Peter Keitler wrote:
>>I did and I could reproduce it. Thanks for the testcase. The fix I
>>applied looks certainly wierd, but it works for me. Would you mind to
>>give the next snapshot a try which
On Apr 27 11:21, Peter Keitler wrote:
The "rsync hangs" problem is not actually a new one. We had
these reports already ages ago. However, *nobody* so far having that
problem seem to be willing to actually debug this problem and track it
down. Grrr.
Corinna,
maybe, the amount
On Apr 27 05:35, Brett Serkez wrote:
> Corinna,
>
>
> > The "rsync hangs" problem is not actually a new one. We had
> > these reports already ages ago. However, *nobody* so far having that
> > problem seem to be willing to actually debug this problem and track it
> > down. Grrr.
>
> This i
On Apr 27 07:50, Brett Serkez wrote:
> > If there is something I can do in order to narrow down the problem,
> > please let me know. This issue has already been discussed on the rsync
> > list (https://bugzilla.samba.org/show_bug.cgi?id=2957) and Wayne from
> > the rsync project was quite sure abou
On Apr 27 11:21, Peter Keitler wrote:
>
> > The "rsync hangs" problem is not actually a new one. We had
> >these reports already ages ago. However, *nobody* so far having that
> >problem seem to be willing to actually debug this problem and track it
> >down. Grrr.
>
> Corinna,
>
> maybe, th
- Original Message -
From: "Dave Korn" <[EMAIL PROTECTED]>
That's a known issue, and one which I'd like to try and work on
...
Unfortunately it doesn't seem possible to set a breakpoint on that function
in either windbg or gdb, so it looks very much like I'm gonna hafta break out
the fu
On 26 April 2006 20:34, Steven Hartland wrote:
> Interestingly if I try to get a thread dump using
> sysinternals process explorer the rsync process goes
> mad using all available cpu.
>
That's a known issue, and one which I'd like to try and work on, but it's
really complex. It's a side-eff
> If there is something I can do in order to narrow down the problem,
> please let me know. This issue has already been discussed on the rsync
> list (https://bugzilla.samba.org/show_bug.cgi?id=2957) and Wayne from
> the rsync project was quite sure about what he called the "Cygwin's
> pipe-data bu
On 27 April 2006 10:45, Brett Serkez wrote:
>
>> Doesn't even run once for me. Creating all the files over ssh works fine
>> but the rsync invocation fails with
>>
>>
>> (Client) Protocol versions: remote=1919251285, neg
> Doesn't even run once for me. Creating all the files over ssh works fine
> but the rsync invocation fails with
>
>
> (Client) Protocol versions: remote=1919251285, negotiated=29
> protocol version mismatch -- is your she
Corinna,
> The "rsync hangs" problem is not actually a new one. We had
> these reports already ages ago. However, *nobody* so far having that
> problem seem to be willing to actually debug this problem and track it
> down. Grrr.
This is exactly fair, several individuals did their best to d
The "rsync hangs" problem is not actually a new one. We had
these reports already ages ago. However, *nobody* so far having that
problem seem to be willing to actually debug this problem and track it
down. Grrr.
Corinna,
maybe, the amount of files has to be increased in order to provoke
On Apr 26 15:22, Ren? Berber wrote:
> Steven Hartland wrote:
> [snip]
> > tcsh is the default shell on FreeBSD which is the "recieving"
> > end in this test yes but I'm a little confused how the shell
> > could effect the results of rsync? FreeBSD to FreeBSD for FreeBSD
> > to Windows SFU doesnt ha
- Original Message -
From: "René Berber"
Then it must be something different.
Thanks for option Rene, always worth investigating these things :)
Steve
This e.mail is private and confidential between Multiplay (UK) Ltd. and the pe
Steven Hartland wrote:
[snip]
> tcsh is the default shell on FreeBSD which is the "recieving"
> end in this test yes but I'm a little confused how the shell
> could effect the results of rsync? FreeBSD to FreeBSD for FreeBSD
> to Windows SFU doesnt have this issue so something specific to
> tcsh on
- Original Message -
From: "René Berber"
Steven Hartland wrote:
Just to back this up, we cant get basic rsync to run reliably
using cygwin either. The command being tested is run from a
FreeBSD box with the source being a cygwin box using cygwin
1.5.19-4:
rsync -av cygwin1:/testdir/ /test
Steven Hartland wrote:
> Just to back this up, we cant get basic rsync to run reliably
> using cygwin either. The command being tested is run from a
> FreeBSD box with the source being a cygwin box using cygwin
> 1.5.19-4:
> rsync -av cygwin1:/testdir/ /testdir/
>
> The result is it will randomly
Just to back this up, we cant get basic rsync to run reliably
using cygwin either. The command being tested is run from a
FreeBSD box with the source being a cygwin box using cygwin
1.5.19-4:
rsync -av cygwin1:/testdir/ /testdir/
The result is it will randomly hang on a file, no output / error
re
Dave Korn wrote:
> On 26 April 2006 17:01, Corinna Vinschen wrote:
>
>
>>On Apr 26 11:51, Peter Keitler wrote:
>>
>>>For the script to run, a sshd has to started on the local machine and
>>>the user name has to be adapted within the script. Could some of you
>>>please run the script twice (the er
On 26 April 2006 17:01, Corinna Vinschen wrote:
> On Apr 26 11:51, Peter Keitler wrote:
>> For the script to run, a sshd has to started on the local machine and
>> the user name has to be adapted within the script. Could some of you
>> please run the script twice (the error only occurs when the fi
On Apr 26 11:51, Peter Keitler wrote:
> For the script to run, a sshd has to started on the local machine and
> the user name has to be adapted within the script. Could some of you
> please run the script twice (the error only occurs when the files
> already exist on the client side) in order to
Hi,
there has been a discussion about Cygwin hangs last December/January. I
think the problem is still alive. I tested with the current snapshot of
cygwin dll (2006-04-24). I can reproduce it with the short script
attached on my WinXP (all patches applied via online update). The script
genera
On Mon, 2 Jan 2006, Lapo Luchini wrote:
> Corinna Vinschen writes:
> > On Dec 30 17:23, Brett Serkez wrote:
> > > I have rsync working over ssh on Cygwin.
> >
> > Me too. I'm using the standard version of rsync, so I guess the
> > socketpair call is still in use.
>
> I never managed to reprod
Larry Hall (Cygwin) wrote:
Maybe it's worth a little archive searching before putting much effort
into generating alternative package configurations for
consideration/use. Just a thought.
Unfortunately I won't have much time to dig in the problem deeper until
I remove my thesis from the TODO l
Lapo Luchini wrote:
Corinna Vinschen writes:
> On Dec 30 17:23, Brett Serkez wrote:
> > I have rsync working over ssh on Cygwin.
>
> Me too. I'm using the standard version of rsync, so I guess the
> socketpair call is still in use.
I never managed to reproduce that problem, neither, on an
Corinna Vinschen writes:
> On Dec 30 17:23, Brett Serkez wrote:
> > I have rsync working over ssh on Cygwin.
>
> Me too. I'm using the standard version of rsync, so I guess the
> socketpair call is still in use.
I never managed to reproduce that problem, neither, on any of my hosts.
(and I alwa
On Dec 30 17:23, Brett Serkez wrote:
> After running into the hang trying to use rsync over ssh on Cygwin,
> reported on this mailing list, but with no resolution other than use of
> daemon mode, I tracked down the problem. I have rsync working over ssh
> on Cygwin.
Me too. I'm using the standar
After running into the hang trying to use rsync over ssh on Cygwin,
reported on this mailing list, but with no resolution other than use of
daemon mode, I tracked down the problem. I have rsync working over ssh
on Cygwin.
The hang is occuring when rsync is attempting to exchange protocol
version
78 matches
Mail list logo
