[EMAIL PROTECTED] [[EMAIL PROTECTED]] writes:
> Actually, the lack of -W isn't helping me at all. The reason is that
> even for the stuff I do over the network, 99% of it is compressed with
> gzip or bzip2. If the files change, the originals were changed and a
> new compression is made, and usu
David Bolen wrote:
> The discovery phase will by default just check timestamps and sizes.
> You can adjust that with command line options, including the use of -c
> to include a full file checksum as part of the comparison, if for
> example, files might change without affecting timestamp or size.
[EMAIL PROTECTED] [[EMAIL PROTECTED]] writes:
>Dave Dykstra wrote:
>
>> That's two different kinds of checksums. The -c option runs a whole-file
>> checksum on both sides, but if you don't use -W the rsync rolling
checksum
>> will be applied.
>
>So the chunk-by-chunk checksum always is used w/o
I am getting this error,
read error: Connection reset by peer
Why is this happening?
Solaris 7 to Solaris 7
rsync v-2.4.1
rsync -a -z --address ${IP} /data/test user@${hostIP}::root/data
Matt
On Fri, May 25, 2001 at 04:33:28PM -0500, Phil Howard wrote:
> Dave Dykstra wrote:
> > > One possibility here is that I do have /var/run symlinked to /ram/run
> > > which is on a ramdisk. So the lock file is there. The file is there
> > > but it is empty. Should it have data in it? BTW, it was
On Fri, May 25, 2001 at 03:39:31PM -0500, Phil Howard wrote:
> Dave Dykstra wrote:
>
> > > 2 =
> > > When syncronizing a very large number of files, all files in a large
> > > partition, rsync frequently hangs. It's abou
Dave Dykstra wrote:
> > 2 =
> > When syncronizing a very large number of files, all files in a large
> > partition, rsync frequently hangs. It's about 50% of the time, but
> > seems to be a function of how much work ther
On Fri, May 25, 2001 at 12:14:17PM -0500, Phil Howard wrote:
> I switched to 2.4.6 a while back, but have only been making heavy
> use of rsync the past couple of months, and have been running into
> a few problems that may be bugs. I looked at the bug tracker, but
> it was too cumbersome to use
> It's not disk space that's needed, it's process memory. I don't know
> the exact number of bytes or on which side though.
Here's an old message of mine when I tried to do a simple analysis - it was
based on 2.4.3 source, but it's probably still fairly close. (a followup
note corrected the fir
On Fri, May 25, 2001 at 12:27:45PM +1000, Colin Nathan wrote:
> Hi all, hope you can help
>
> We are mounting a NetWare 5.x volume using NCP and then attempting to
> syncronise between two local folders on this particular Linux server.
>
> Problem 1.
>
> The syncronisation occasionally "gets st
I switched to 2.4.6 a while back, but have only been making heavy
use of rsync the past couple of months, and have been running into
a few problems that may be bugs. I looked at the bug tracker, but
it was too cumbersome to use effectively. I don't know if these
are real bugs or just configurati
On Fri, May 25, 2001 at 11:29:48AM -0400, dywang wrote:
> hi, there,
>
> I understand that rsync need about 100Bytes for every file to be transfered
> in order to build the file list.
>
> Could anyone tell me where this space is needed, on the machine where rsync
> initiated, or the remote machi
hi, there,
I understand that rsync need about 100Bytes for every file to be transfered
in order to build the file list.
Could anyone tell me where this space is needed, on the machine where rsync
initiated, or the remote machine, or both?
e.g.at BOX A:
Box-A#rsync -avz -e ssh dir-a someone@
hi, there,
I understand that rsync need about 100Bytes for every file to be transfered
in order to build the file list.
Could anyone tell me where this space is needed, on the machine where rsync
initiated, or the remote machine, or both?
e.g.at BOX A:
Box-A#rsync -avz -e ssh dir-a someone@
14 matches
Mail list logo
