On Fri, Jan 31, 2003 at 12:09:14PM +0100, Lapo Luchini wrote:
Max Bowsher wrote:
Unless someone feels like making a FAT-detection patch, the previous status
quo looks to me like the best option.
Would creating a file in the same dir be too invasive?
Of course this would only solve the
On Fri, Jan 31, 2003 at 02:12:45PM -, Max Bowsher wrote:
jw schultz wrote:
On Fri, Jan 31, 2003 at 12:09:14PM +0100, Lapo Luchini wrote:
Would creating a file in the same dir be too invasive?
Of course this would only solve the problem if one file is
created/tested per directory...
jw schultz wrote:
I'd rather we default modify-window to 1 for windows.
But windows != FAT. Even a Linux system *could* be using FAT. What's wrong
with the current state of affairs?
It's not like the mailing list (rsync or cygwin) is flooded with messages
complaining about this.
Max.
--
To
On Fri, Jan 31, 2003 at 02:44:58PM -, Max Bowsher wrote:
jw schultz wrote:
I'd rather we default modify-window to 1 for windows.
But windows != FAT. Even a Linux system *could* be using FAT. What's wrong
with the current state of affairs?
It's not like the mailing list (rsync or
jw schultz wrote:
On Fri, Jan 31, 2003 at 02:44:58PM -, Max Bowsher wrote:
jw schultz wrote:
I'd rather we default modify-window to 1 for windows.
But windows != FAT. Even a Linux system *could* be using FAT. What's
wrong with the current state of affairs?
It's not like the mailing
Dave Dykstra wrote:
On Sat, Jan 25, 2003 at 06:32:08PM +0100, Greger Cronquist wrote:
--- Max Bowsher [EMAIL PROTECTED] skrev: Dave Dykstra
wrote:
I'm using the current Cygwin release
(rsync-2.5.5-2). That is rsync-2.5.5,
with an added msleep(30) which is intended to deal
with a possible
On Fri, Jan 24, 2003 at 05:18:07PM -0600, Dave Dykstra wrote:
I had a friend run some Cygwin tests and we found that --modify-window=1
works just as well as --modify-window=2 on FAT filesystems to copy files
from Unix and detect the difference in granularity. FAT filesystems always
have
Dave Dykstra wrote:
This modify-window default of 1 has been causing some trouble on the
rsync test suite on the Cygwin test machine on build.samba.org. The
problem is that some files get created and immediately copied within
one second, and then the rsync code that implements '-p' checks to
On Mon, Jan 27, 2003 at 04:38:09PM -, Max Bowsher wrote:
Dave Dykstra wrote:
This modify-window default of 1 has been causing some trouble on the
rsync test suite on the Cygwin test machine on build.samba.org. The
problem is that some files get created and immediately copied within
On Mon, Jan 27, 2003 at 03:57:16PM -0600, Dave Dykstra wrote:
On Mon, Jan 27, 2003 at 04:38:09PM -, Max Bowsher wrote:
Dave Dykstra wrote:
This modify-window default of 1 has been causing some trouble on the
rsync test suite on the Cygwin test machine on build.samba.org. The
Thanks, you saved me some trouble. I put it in.
- Dave
On Mon, Jan 27, 2003 at 06:52:30PM -0800, jw schultz wrote:
On Mon, Jan 27, 2003 at 03:57:16PM -0600, Dave Dykstra wrote:
On Mon, Jan 27, 2003 at 04:38:09PM -, Max Bowsher wrote:
Dave Dykstra wrote:
This modify-window default
On Sat, Jan 25, 2003 at 06:32:08PM +0100, Greger Cronquist wrote:
--- Max Bowsher [EMAIL PROTECTED] skrev: Dave Dykstra
wrote:
I'm using the current Cygwin release
(rsync-2.5.5-2). That is rsync-2.5.5,
with an added msleep(30) which is intended to deal
with a possible problem
with
http://lists.samba.org/pipermail/rsync/2002-August/008130.html
but it still experienced hangs. It wasn't clear if the patch reduced
the frequency or not.
It didn't fix it for us. We sync Win9x clients to a Win2k server running
rsync as service.
Hangs and connection reset by peer
Has *anybody* been able to figure out a fix for this that really works?
Why does the receiving child wait in a loop to get killed, rather than
just exit()? I presume cygwin has some problem or race condition in the
wait loop, kill and wait_process().
The pipe to the parent will read 0 bytes
On Fri, Jan 24, 2003 at 05:18:07PM -0600, you [Dave Dykstra] wrote:
While doing the tests we too experienced hangs at the end of copies.
We were going over openssh from a Solaris 9 box to Windows 2000 Cygwin.
We tried the test from
Dave Dykstra wrote:
On Sat, Jan 25, 2003 at 12:10:39AM -, Max Bowsher wrote:
Dave Dykstra wrote:
While doing the tests we too experienced hangs at the end of copies.
We were going over openssh from a Solaris 9 box to Windows 2000
Cygwin.
We tried the test from
--- Max Bowsher [EMAIL PROTECTED] skrev: Dave Dykstra
wrote:
I'm using the current Cygwin release
(rsync-2.5.5-2). That is rsync-2.5.5,
with an added msleep(30) which is intended to deal
with a possible problem
with signals in Cygwin.
Making that msleep(100) works even better for me.
I had a friend run some Cygwin tests and we found that --modify-window=1
works just as well as --modify-window=2 on FAT filesystems to copy files
from Unix and detect the difference in granularity. FAT filesystems always
have timestamps that have an even number of seconds. On the other hand,
Dave Dykstra wrote:
While doing the tests we too experienced hangs at the end of copies.
We were going over openssh from a Solaris 9 box to Windows 2000
Cygwin.
We tried the test from
http://lists.samba.org/pipermail/rsync/2002-August/008130.html
but it still experienced hangs. It
19 matches
Mail list logo
