> 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 happe
> 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 (E
Well I was hoping to get the 2.5.6 out today, but I think I made too many
Cygwin changes this evening for comfort and I'd like to allow one more
day of testing. Cygwin users, please test as much as you can and post
any problems.
- Dave Dykstra
--
To unsubscribe or change options: http://lists.sa
Hello
rsync-2.5.5 for hp-ux 11.0 is not syncing files more that 2 GB ( largefile ) .
Should i need to recompile rsync ?
Should i use any special options while compiling ?
please help.
-babu
__
The NEW Netscape 7.0 browser is n
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 pr
On Sun, Jan 26, 2003 at 02:46:43PM -0800, Craig Barratt wrote:
> > Is there any reason why caching programs would need to set the
> > value, rather than it just being a fixed value?
> > I think it is hard to describe what this is for and what it should be
> > set to. Maybe a --fixed-checksum-seed
On Sun, Jan 26, 2003 at 06:04:52PM -0800, Craig Barratt wrote:
> > Block checksums come from the receiver so cached block
> > checksums are only useful when sending to a server which had
> > better know it has block checksums cached.
>
> The first statement is true (block checksums come from the r
> Block checksums come from the receiver so cached block
> checksums are only useful when sending to a server which had
> better know it has block checksums cached.
The first statement is true (block checksums come from the receiver),
but the second doesn't follow. I need to cover the case where
On Sun, Jan 26, 2003 at 02:46:43PM -0800, Craig Barratt wrote:
> > Is there any reason why caching programs would need to set the
> > value, rather than it just being a fixed value?
> > I think it is hard to describe what this is for and what it should be
> > set to. Maybe a --fixed-checksum-seed
> Is there any reason why caching programs would need to set the
> value, rather than it just being a fixed value?
> I think it is hard to describe what this is for and what it should be
> set to. Maybe a --fixed-checksum-seed option would make some sense,
> or for a caching mechanism to be built
Dave Dykstra wrote:
> On Sun, Jan 26, 2003 at 08:54:19PM -, Max Bowsher wrote:
>> Dave Dykstra wrote:
>>> Alright. Max, could you quickly verify if the latest CVS version
>>> works OK for you on Cygwin?
>>
>> What, in particular? I'm not a very good testcase, because I use
>> binary mounts and
Is there any reason why caching programs would need to set the
value, rather than it just being a fixed value? I think it is hard
to describe what this is for and what it should be set to. Maybe a
--fixed-checksum-seed option would make some sense, or for a caching
mechanism to be built in to rsy
On Sun, Jan 26, 2003 at 08:54:19PM -, Max Bowsher wrote:
> Dave Dykstra wrote:
> > Alright. Max, could you quickly verify if the latest CVS version
> > works OK for you on Cygwin?
>
> What, in particular? I'm not a very good testcase, because I use binary
> mounts and unix line endings everyw
Dave Dykstra wrote:
> Alright. Max, could you quickly verify if the latest CVS version
> works OK for you on Cygwin?
What, in particular? I'm not a very good testcase, because I use binary
mounts and unix line endings everywhere.
It compiles and does syncs with remote rsync daemons, which is my
Alright. Max, could you quickly verify if the latest CVS version works
OK for you on Cygwin?
It's better to always handle all three styles of line terminations anyway,
because there are other situations than systems that have O_TEXT defined
where it might be wanted, for example a Linux system tha
On Sun, Jan 26, 2003 at 08:16:50AM -0800, jw schultz wrote:
> authenticate.c: fd = open(fname,O_RDONLY | O_TEXT);
> get_secret() already discards \r
>
> authenticate.c: if ( (fd=open(filename,O_RDONLY | O_TEXT)) == -1) {
> getpassf() treats \r the same as \n
Yeah, these already handle
Even though it was a pain in the *ss, I broke up the transfer into
several chunks (logically organized by sub-directories of the source)
and wrote a script to batch the job. It worked, better and faster than
via NFS. Mounting the source directory via NFS is not a solution that
makes one feel good
On Sun, Jan 26, 2003 at 09:43:06AM -0500, Green, Paul wrote:
> Ville Herva [mailto:[EMAIL PROTECTED]] wrote:
> > Of course, whether O_TEXT is defined or not does not
> > necessarily imply the availability of "t", but I
> > can't think of better alternative.
>
> Stratus VOS implements O_TEXT and O
Quoting Dave Dykstra ([EMAIL PROTECTED]) from 25 January 2003:
> I couldn't reproduce the problem on Linux, but I believe you that it's
> a problem. If you think about it, it's easy to see why code that called
> _exit_cleanup() might behave strangely if the function returns so I
> like the fix of
Ville Herva [mailto:[EMAIL PROTECTED]] wrote:
> Of course, whether O_TEXT is defined or not does not
> necessarily imply the availability of "t", but I
> can't think of better alternative.
Stratus VOS implements O_TEXT and O_BINARY but does not recognize "t". We
have the options defined in ANS C
20 matches
Mail list logo
