I see rsync has this in rsync.h
#ifndef HAVE_LCHOWN
#define lchown chown
#endif
So on Linux lchown changes the ownership on a symlink, whereas chown
on a symlink will change the ownership of its target. man lchown says
In versions of Linux prior to 2.1.81 (and distinct from
On 30 Nov 2001, Thomas J Pinkl [EMAIL PROTECTED] wrote:
I'm seeing:
bit length overflow
code 4 bits 6-7
in the output of rsync 2.5.0 between two Red Hat Linux systems.
One is RH 6.1 (kernel 2.2.19-6.2.1, glibc 2.1.3-22), the other
is RH 7.2 (kernel 2.4.9-13, glibc 2.2.4-19). Both
I compiled and tried rsync 2.5.0 but could not get the server
running. loadparm.c:string_set() now calls free() which it did not do
in 2.4.6 and this free() tries to free memory that was not allocated
with malloc.
Here is a gdb run (done after adding return before fork() in
become_daemon) which
Does anybody care about supporting non-English message locales in
rsync? (Do all sysadmins speak English? :-) Would anybody contribute
translations if we had the framework?
--
Martin
On 2 Dec 2001, Heikki Vatiainen [EMAIL PROTECTED] wrote:
I compiled and tried rsync 2.5.0 but could not get the server
running. loadparm.c:string_set() now calls free() which it did not do
in 2.4.6 and this free() tries to free memory that was not allocated
with malloc.
Thankyou for the
Martin Pool wrote:
On 30 Nov 2001, Thomas J Pinkl [EMAIL PROTECTED] wrote:
I'm seeing:
bit length overflow
code 4 bits 6-7
in the output of rsync 2.5.0 between two Red Hat Linux systems.
One is RH 6.1 (kernel 2.2.19-6.2.1, glibc 2.1.3-22), the other
is RH 7.2 (kernel
On 30 Nov 2001, Tom Schmidt [EMAIL PROTECTED] wrote:
Attached is a patch for rsync 2.5.0 to fix the make check option.
Thankyou, commmitted.
--
Martin
On 30 Nov 2001, Randy Kramer [EMAIL PROTECTED] wrote:
I am not sure which end the 100 bytes per file applies to, and I guess
that is the RAM memory footprint?. Does rsync need 100 bytes for each
file that might be transferred during a session (all files in the
specified directory(ies)), or
I'm starting to think we need to not show all the options in the
default --help output. I think perhaps the default should be to show
the commonly-used options (-avz, --include, : vs ::) and then have
--help-options and so on for more details. It is getting quite
ridiculous. There's one or two
I compiled and tried rsync 2.5.1pre1.
RSYNC with -F option dumps a core.
% gdb ./rsync
GNU gdb 5.1
(gdb) r -F
Starting program: /work/rsync-2.5.1pre1/./rsync -F
Program received signal SIGSEGV, Segmentation fault.
write_batch_argvs_file (orig_argc=-2, argc=0, argv=0x0) at batch.c:153
153
The problem shows in the following log snippet. The numeric address of
the peer (localhost in this case) is garbage.
rsyncd[32671]: reverse name lookup failed
rsyncd[32671]: rsync: forward name lookup for failed: Name or service not known
rsyncd[32671]: rsync on debian/ from UNKNOWN
If it's what I suspect, answer these questions:
Are all the keys different? (You have to say yes here.)
Yes, should have thought to make that clear initially.
Are you using an ssh-agent at the calling end? (You want no here,
and a -i keyfile in the ssh call.)
Nope.
Hi all,
I've asked this question before, but I was never able to fix the problem,
and now it's back again and I'd like to try and resolve it.
I have an authorized_keys file with about twenty keys, most of which are
prefaced with command=/usr/bin/rsync If I put my host key at the
top of the
On 28 Nov 2001, [EMAIL PROTECTED] wrote:
Hello all
I have been watching and learning from this list for a couple of months
now.. Here is my first question.
If rsync comes across a file that is in use by somebody. What happens?
Does the file get skipped or does the entire transfer halt?
14 matches
Mail list logo
