One of my pet peeves with rsync is that I too often end up writing
1. rsync a/ h:
when I meant
2. rsync a h:
This is because my shell leaves the trailing slash when I complete
directories. I'm not going to reconfigure my shell just for rsync -
besides, I like the trailing slash as a visual
(Email attachment quoted for the benefit of the mail archive...)
On Thu, 3 Mar 2005, michael mendoza [EMAIL PROTECTED] wrote:
Hi, thank again.
I used rsync today to copy 400 MB from a pc to other
pc with rsync -avz -e ssh SourceDir
[EMAIL PROTECTED]:/dirDest/
but in the source pc i
Lars Karlslund wrote:
And I'm suggesting making it static, by adjusting the hash table's size
according to the number of blocks. Just do
hashtablesize=(numblocks/8+1)*10;, and you should be set.
Or maybe it should really be dynamic.
I'm talking about the hash table load. I.e. - the ratio
Kevin Day wrote:
As a quick FYI, the block size absolutely has an impact on the
effectiveness of the checksum table - larger blocks means fewer
blocks, which means fewer hash colissions.
Since you wouldn't expect that many blocks in the file, a 32bit weak
checksum would only produce about 4 or
Hi everyone,
Previously I was using RSYNC 2.5.7 on RedHat 8.0 to
mirror CPAN (http://www.cpan.org/) and LDP
(http://www.tldp.org/) and everything was working
fine.
After upgrading to Fedora Core 2 and using RSYNC 2.6.x
, I kept on getting the following errors:
# rsync -av --stats --delete
On Wednesday 02 March 2005 06:11 pm, Scott Becker wrote:
I've been researching the state of 'file alteration monitoring'
technology on Linux. Famd uses dnotify to inefficently monitor a handful
of directories. The replacement for dnotify is being worked on in the
kenel and it's called inotify.
On Sat, Mar 05, 2005 at 02:18:01PM +0200, Shachar Shemesh wrote:
That's not what I read into it. It seems to me that the checksum
function gives a 32bit result, and we are squashing that into a 16bit
hash table. Can you point me to the code? Wayne?
Look in match.c. The hash table is
On Thu, Mar 03, 2005 at 10:18:01AM +0200, Shachar Shemesh wrote:
And I'm suggesting making it static, by adjusting the hash table's
size according to the number of blocks.
The block-size? No thanks. The smaller the block-size for a particular
file size, the more checksum data needs to be
[I accidentally sent this reply only to Lars instead of the list.]
On Fri, Mar 04, 2005 at 06:44:48PM +0100, Lars Karlslund wrote:
I read somewhere about the default blocksize of 700 bytes. Now I'm
told the blocksize is calculated automatically. Which is it?
700 is the minimum block-size. The
On Fri, Mar 04, 2005 at 11:13:22PM +0100, Paul Slootman wrote:
0 100%0.00kB/s 519:35:46 (61, 56.3% of 597)
This is quite reproducable whenever an empty file is transferred (or
created on the receiving end).
This is caused by the ph_start.time value being 0 for a 0-length
Wayne Davison wrote:
On Thu, Mar 03, 2005 at 10:18:01AM +0200, Shachar Shemesh wrote:
And I'm suggesting making it static, by adjusting the hash table's
size according to the number of blocks.
The block-size?
Definitely not! I was talking about the hash table load. I.e. - the
ratio
On Sat 05 Mar 2005, Wayne Davison wrote:
I don't quite see the point of setting diff to 1ms if it's zero...
Because an elapsed time of 0 means that any data that arrived, arrived
very quickly. Setting the rate to 0 when the elapsed time is 0 is the
opposite of what we need -- an infinite
On Sat, Mar 05, 2005 at 07:44:06PM +0100, Paul Slootman wrote:
the else branch of the if did a diff ? bla /diff : 0
Yeah, my patch also changed that to make it consistent (but I didn't
mention it in my email). I believe that in the else branch it is
impossible for diff to ever be 0 (which is
Wayne Davison wrote:
He's talking about potentially losing an even distribution of values
if the lowest order bits aren't random enough.
On Sat, Mar 05, 2005 at 08:10:37PM +0200, Shachar Shemesh wrote:
Even for N which is not a power of 2?
In the case of the weak checksum, it is computed
On Sat, Mar 05, 2005 at 12:33:27AM -0800, Frederik Eaton wrote:
what would be nicer is an option to turn off the special
interepretation of terminal slashes in source paths.
That would be easy enough to do in a shell function that you could use
to wrap up your rsync invocations. It would scan
On Sat, Mar 05, 2005 at 05:54:28PM -0800, Frederik Eaton wrote:
It breaks some functionality of the
--include and --exclude options:
True. You can work around that problem if you always use an '=' to
connect the option to its arg by adding a new match to the case in that
function:
Date: Sat Mar 5 17:49:46 2005
Author: wayned
Update of /data/cvs/rsync
In directory dp.samba.org:/tmp/cvs-serv20644
Modified Files:
progress.c
Log Message:
Fixed the elapsed time reported for 0-length files.
Revisions:
progress.c 1.11 = 1.12
Date: Sat Mar 5 17:51:23 2005
Author: wayned
Update of /data/cvs/rsync
In directory dp.samba.org:/tmp/cvs-serv20929
Modified Files:
match.c sender.c
Log Message:
Moved the end_progress() call from match.c to sender.c so that we
report progress on 0-length files when pushing files
Date: Sat Mar 5 18:58:26 2005
Author: wayned
Update of /data/cvs/rsync
In directory dp.samba.org:/tmp/cvs-serv6327
Modified Files:
rsync.yo rsync.1
Log Message:
Mention that --max-delete must be non-zero.
Revisions:
rsync.yo1.260 = 1.261
Date: Sat Mar 5 18:58:32 2005
Author: wayned
Update of /data/cvs/rsync
In directory dp.samba.org:/tmp/cvs-serv6366
Modified Files:
errcode.h
Log Message:
Added RERR_DEL_LIMIT.
Revisions:
errcode.h 1.8 = 1.9
Date: Sat Mar 5 18:58:42 2005
Author: wayned
Update of /data/cvs/rsync
In directory dp.samba.org:/tmp/cvs-serv6423
Modified Files:
generator.c
Log Message:
- When --max-delete is exceeded, we now count how many deletions
would have happend, warn about the number skipped, and set
21 matches
Mail list logo
