RE: question on switches and their order

2001-06-25 Thread Wilson, Mark - MST
Jeff Ordering of switches is important, but only for the --include* --exclude* switches. For your sample command there should be no difference. We also use NetApp filers and exclude .snapshot, the same way you have. It works fine... The --delete command won't help here as it will delete

RE: question on switches and their order

2001-06-25 Thread Wilson, Mark - MST
Leave out the --delete. It will delete everything on the destination that is not present on the source, except for .snapshot -if present. If you want to play with --delete use the -n option as well. This will tell you what rsync is going to do without actually doing anything. Suggest you try

RE: librsync and network functions

2001-06-13 Thread Wilson, Mark - MST
Martin To tridge and I, rsync 2.x is essentially in maintenance mode at the moment: it doesn't seem like a good investment to add more features or functionality to the codebase. A better way to improve it is to build a new, cleaner protocol. Does this mean there is a version 3.x on its way?

RE: rsync hangs in select on linux 2.4.5

2001-06-13 Thread Wilson, Mark - MST
Wayne Umm, errr, I have to confess that I don't know how to apply your hang patch... I did try the patch command, but to no avail. A quick explanation would be appreciated. I have: -downloaded the rsync-2.4.6 source and unpacked it. -am using Solaris 2.6. -am using Solaris compilers and

RE: rsync fails

2001-05-17 Thread Wilson, Mark - MST
Rsh only sets up a limited path for you. Do the command: rsh remote_host echo \$PATH (or ssh remote_host echo \$PATH) and this will tell you what your remote PATH is. Perhaps install rsync into one of these directories or use sym links. If you are using ssh have a look at the man page about

RE: FW: Problem with large include files

2001-05-15 Thread Wilson, Mark - MST
- From: Dave Dykstra [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 16 May 2001 01:24 To: Wilson, Mark - MST Cc: RSync List (E-mail) Subject: Re: FW: Problem with large include files On Tue, May 15, 2001 at 03:31:23PM +1200, Wilson, Mark - MST wrote: ... Do you have any idea what the maximum number

FW: Problem with large include files

2001-05-14 Thread Wilson, Mark - MST
Try rsync 2.3.2 on both ends and see what the result is. What transport method are you using (rsh, ssh, or rsync --daemon mode)? --daemon mode. Some tests a colleague did showed a performance advantage. Come to think of it, I know from experience that rsync is able to keep the TCP

RE: Problem with large include files

2001-05-13 Thread Wilson, Mark - MST
[mailto:[EMAIL PROTECTED]] Sent: Saturday, 12 May 2001 01:43 To: Wilson, Mark - MST Cc: RSync List (E-mail) Subject: Re: Problem with large include files On Fri, May 11, 2001 at 11:41:41AM +1200, Wilson, Mark - MST wrote: Hi there I recently tried to do a transfer of a directory tree with about

Problem with large include files

2001-05-10 Thread Wilson, Mark - MST
Hi there I recently tried to do a transfer of a directory tree with about 120,000 files. I needed to select various files and used the --include-from option to select the files I needed to transfer. The include file had 103,555 filenames in it. The problem I have is that the transfer quit after

Sending large file across a 10Mbit link

2001-03-20 Thread Wilson, Mark - MST
Hi there I am new to rsync lists so may be posting this message to the wrong place. Please let me know if I am. We are using rsync to to send large files (larger than 2Gb) across a 10Mbit link (burstable to 30Mbit) using rsync. The link has a return latency of about 52ms. In speed comparisons

RE: Sending large file across a 10Mbit link

2001-03-20 Thread Wilson, Mark - MST
Hmm, under those conditions, to be honest, is rsync even appropriate? You could just copy the file with rcp/scp (heck, or even ftp). You're not benefitting at all from rsync's algorithm. Oops, there was a mistake. The compressed file was 227Mb (2G uncompressed). The features we want to use