Displaying 5 results from an estimated 5 matches for "mattlaptop2".
Did you mean:
mattlaptop
2007 Aug 05
1
Pulling multiple sources from a daemon
What is the official syntax for pulling multiple sources from a
daemon? In analogy to a remote shell, I expected this to work:
rsync rsync://matt@mattlaptop2:3141/module/'foo bar' dest/
But it doesn't; the daemon tried to access a file 'foo bar' with a
space in its name.
Using a newline like this does work because the newline becomes an
argument delimiter in the daemon protocol:
rsync rsync://matt@mattlaptop2:3141/module/'foo...
2007 Jul 02
3
DO NOT REPLY [Bug 4757] New: Daemon mis-logs paths if module path in rsyncd.conf is relative
...rsyncd.conf:
log file = rsyncd.log
transfer logging = yes
log format = %i %f
pid file = rsyncd.pid
port = 3142
use chroot = no
[module]
path = dir/
read only = false
auth users = user
secrets file = module.secrets
Then I pushed a directory to it as follows:
[matt@mattlaptop2 daemon-log-paths]$ pwd
/home/matt/test/daemon-log-paths
[matt@mattlaptop2 daemon-log-paths]$ ls -l src
total 0
-rw------- 1 matt matt 0 2007-07-01 18:06 a
[matt@mattlaptop2 daemon-log-paths]$ ls -l daemon/dir/subdir
total 0
-rw------- 1 matt matt 0 2007-07-01 18:06 b
[matt@mattlaptop2 daemon-log-pa...
2009 Oct 29
2
exit status 13 in version 3.1
Got this in the log:
rsync error: errors with program diagnostics (code 13) at log.c(340) [generator=
3.1.0dev]
What could it be? I suspect it's triggered by a timeout or disconnect
from the server side but I had never seen it.
2008 Oct 09
2
Possible 3.0.4 bug with -s (--protect-args) - protocol error
Hi.
Two different hosts with 3.0.4 compiled from source, no patches.
It seems fine except that -s causes protocol failures. See below.
Local host is Sparc (Solaris 5.8), remote is Sparc (Solaris 5.10) or i686 Linux.
Regards,
Giuliano.
userX@hostA$ /home/userX/tools/bin/rsync -v -v -v -v -v -n
--rsync-path /home/userX/tools/bin/rsync -s . hostB:
FILE_STRUCT_LEN=16, EXTRA_LEN=4
cmd=<NULL>
2007 Nov 05
1
Rsync shouldn't display a meaningless speedup on a dry run
On a dry run, rsync displays a speedup value calculated from the total
size of the source file data and the amount of data sent over the
connection, but this value is meaningless and grossly misleading because
the file data is not sent over the connection. Example:
[matt@mattlaptop2 test]$ rsync -avi -n ~/eclipse/releases/eclipse-SDK-3.3-linux-gtk.tar.gz .
sending incremental file list
>f+++++++++ eclipse-SDK-3.3-linux-gtk.tar.gz
sent 74 bytes received 15 bytes 178.00 bytes/sec
total size is 144352015 speedup is 1621932.75
I think rsync should omit the speedup on a dry...