On 08Jun2005 08:38, Wayne Davison <[EMAIL PROTECTED]> wrote:
| On Wed, Jun 08, 2005 at 02:14:05PM +1000, Cameron Simpson wrote:
| > in short, rsync is seeing the "[EMAIL PROTECTED]" and invoking:
| > ssh ali -l root rsync-daemon-invocation...
|
| This should only happen if remsh is present on
On Wed, Jun 08, 2005 at 02:14:05PM +1000, Cameron Simpson wrote:
> in short, rsync is seeing the "[EMAIL PROTECTED]" and invoking:
>
> ssh ali -l root rsync-daemon-invocation...
This should only happen if remsh is present on your system when
configure was run. This is because remsh require
The latest rsync (2.6.5) seems to invoke the transport specified by
$RSYNC_RSH differently. I have this set to point at an ssh wrapper script
(which is now I noticed), and an strace shows this:
[archives/[EMAIL PROTECTED]> strace -e trace=process -f /opt/bin/rsync -avHP
/mnt/phat/archives/silva
On Mon, Jun 07, 2004 at 12:23:00AM +0200, Vidar Madsen wrote:
> I'm just reporting some strange (fatal) behaviour when running
> rsync --daemon on an IPv6-enabled box.
This should only affect older systems that don't have a proper IPv6
implementation, such as some older 2.4 Linux kernels. The fix
Hi all.
I'm just reporting some strange (fatal) behaviour when running
rsync --daemon on an IPv6-enabled box. It gets a fatal error
when trying to bind to the same address twice.
strace output:
bind(4, {sa_family=AF_INET6, sin6_port=htons(873), inet_pton(AF_INET6, "::",
&sin6_addr), sin6_flowi
Hi all.
I'm just reporting some strange (fatal) behaviour when running
rsync --daemon on an IPv6-enabled box. It gets a fatal error
when trying to bind to the same address twice.
strace output:
bind(4, {sa_family=AF_INET6, sin6_port=htons(873), inet_pton(AF_INET6, "::",
&sin6_addr), sin6_flowi
On Fri, Apr 02, 2004 at 09:25:51AM -0500, kenneth topp wrote:
> rsync as server, getting something from a module, the server does a
> pushdir on the backup-dir that the client has. It's required to exist!
I can't duplicate that. What version is the daemon running? What
command are you're runn
You're correct. Here is the where it grabes you:
rsync as server, getting something from a module, the server does a
pushdir on the backup-dir that the client has. It's required to exist!
So not really either, this get's you with new clients to either old or new
servers..
have to dig back in
--On Wednesday, March 31, 2004 8:58 AM -0800 Wayne Davison
<[EMAIL PROTECTED]> wrote:
Regardless, you weren't entirely clear what prompted you to mention
this. Inefficiency? Or a compatibility bug?
In thinking about multi-version compatibility, it seems to me that if a
2.5.x client/receiver w
On Wed, Mar 31, 2004 at 08:19:02AM -0500, kenneth topp wrote:
> With this patch (see URL), backup-dir is passed to the server.
Yeah, that change did get made in 2.6.0 (though I don't currently
remember exactly why).
Regardless, you weren't entirely clear what prompted you to mention
this. Ineffi
With this patch (see URL), backup-dir is passed to the server. It's not
currently ignored on the other end if irrelevant (which it is for
senders). Either we should not pass it, or let the sender ignore it
later on.
http://cvs.samba.org/cgi-bin/cvsweb/rsync/options.c.diff?r1=1.109&r2=1.110&f=
On 28 Dec 2003, at 05:15, jw schultz wrote:
On Sun, Dec 28, 2003 at 10:45:52AM +0100, alain content wrote:
Bad, bad Apple.
Look for the thread on this list with the subject
"workaround for HFS+'s case-insensitivity"
One of the messages discusses options for making hpfs case
sensitive.
Sadly, you ca
On Sun, Dec 28, 2003 at 10:45:52AM +0100, alain content wrote:
> Right,
> Renaming does not touch the file - it only changes the directory
> modification date.
>
> And you are absolutely right. Panther preserves case but is insensitive to
> case in file names :
> ls
> >...
> >-rw-r--r-- 1 ac ac
Right,
Renaming does not touch the file - it only changes the directory
modification date.
And you are absolutely right. Panther preserves case but is insensitive to
case in file names :
ls
>...
>-rw-r--r-- 1 ac ac 0 27 Dec 11:59 a file named ABC
filetest -e "a file named ABC"
> 1
filetest
On Sat, Dec 27, 2003 at 04:39:08PM -0800, Jim Salter wrote:
> JW: in this instance, since he used the -a switch, shouldn't have rsync
> sync'ed the file again anyway, since the file modification date would
> (should?) have been updated when he renamed the file?
Renaming a file (per SUSv3 and POS
JW: in this instance, since he used the -a switch, shouldn't have rsync
sync'ed the file again anyway, since the file modification date would
(should?) have been updated when he renamed the file?
Alain: *does* Panther "touch" the file (and update the file modification
datestamp) when you rename
On Sat, Dec 27, 2003 at 12:28:06PM +0100, alain content wrote:
> Hi,
> I found this surprising behavior with rsync (version 2.5.7 protocol
> version 26) on Mac OS X (Panther, 10.3.2) :
>
> Suppose you have a folder "Source" containing a file named "abc", and its
> backup as folder "Clone", cre
Hi,
I found this surprising behavior with rsync (version 2.5.7 protocol
version 26) on Mac OS X (Panther, 10.3.2) :
Suppose you have a folder "Source" containing a file named "abc", and its
backup as folder "Clone", created by rsync :
rsync -a ~/Desktop/Source/ ~/Desktop/Clone
Now change th
jw schultz wrote:
On Thu, Jul 24, 2003 at 09:52:44AM +1000, Peter Chun wrote:
Hi,
I have only just subscribe to the list. ( only to send this bug report )
Running rsync version 2.5.6 protocol version 26 ( on Solaris 8 sparc )
on both hosts.
I have 1 file I wish to sync to a remote
On Thu, Jul 24, 2003 at 09:52:44AM +1000, Peter Chun wrote:
> Hi,
> I have only just subscribe to the list. ( only to send this bug report )
>
> Running rsync version 2.5.6 protocol version 26 ( on Solaris 8 sparc )
> on both hosts.
>
> I have 1 file I wish to sync to a
Hi,
I have only just subscribe to the list. ( only to send this bug report )
Running rsync version 2.5.6 protocol version 26 ( on Solaris 8 sparc )
on both hosts.
I have 1 file I wish to sync to a remote machine
the md5 checksum is
host1: MD5 (030722.mj) = 020397fde83c2e20464b6642c018ce6e
On Tue, Apr 01, 2003 at 10:43:55PM -0500, Daniel Barrett wrote:
>
> When I run "rsync -a" to mirror a large directory structure on Mac OS/X
> 10.2.4, it always (100%) produces a bus error. Small directory structures
> work fine.
>
> The computer in question has 768 MB RAM and 10 GB free disk spac
When I run "rsync -a" to mirror a large directory structure on Mac OS/X
10.2.4, it always (100%) produces a bus error. Small directory structures
work fine.
The computer in question has 768 MB RAM and 10 GB free disk space, so
memory is not a problem. This is rsync 2.5.2 supplied with Mac OS/X.
I have found an unwanted feature of rsync 2.5.5. It has to do with
soft links and the --delete option in archive mode. The following shows
how to reproduce the error.
Provide a soft link that refers to a parent directory.
%> /bin/ls -lR /tmp/src
/tmp/src:
total 16
16 drwxrwxr-x 2 wke
Since writing this I've recompiled with zlib 1.1.4 and everything appears
smooth. Since this is intermittant, I'll send it off anyways in the hops that
someone else may see it. It also *might* apply to the "known issues"
entry about "unexpected close." (Similar symptoms, but it may just be a sh
>2. bug report: errors in file transfer (Michael Lachmann)
Sorry!
It turns out that the problem is bad memory here on my box. And I tried to
blame rsync!
Michael
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: h
Yes you should be concerned about this problem.
I suggest these things:
1. Try running without -z. Some versions of rsync (2.5.4?) had a libz
bug.
2. Better yet, upgrade both sides to 2.5.5 and retry.
3. Make sure your solaris box has the latest NFS patches.
eric
Michael Lachmann wrote:
>
Hi!
I just encountered a serious problem with rsync.
I used rsync to copy a big directory between two computers. The source
machine was a sun, the destination was a linux box. The destination
directory did not exist before the copy started.
I used the following command to copy the directory over
On Sat, May 11, 2002 at 01:35:30AM -0700, Wayne Davison wrote:
> OK, I just checked in a change that uses some of your suggested text to
> remove a bit of the chattiness. I also improved the RSYNC_RSH section
> to mention the legality of command-line options. See if you like it
> better.
>
> --
On Sat, May 11, 2002 at 01:16:27AM -0700, Wayne Davison wrote:
> On Fri, 10 May 2002, jw schultz wrote:
> > Also the example is an odd one.
>
> It doesn't seem odd to me since the -l option is the one that I've used
> most in ssh (when I don't use the config file to avoid all options).
> The impo
OK, I just checked in a change that uses some of your suggested text to
remove a bit of the chattiness. I also improved the RSYNC_RSH section
to mention the legality of command-line options. See if you like it
better.
--- rsync.yo2002/05/09 21:44:46 1.99
+++ rsync.yo2002/05/11 08:31
On Fri, 10 May 2002, jw schultz wrote:
> Also the example is an odd one.
It doesn't seem odd to me since the -l option is the one that I've used
most in ssh (when I don't use the config file to avoid all options).
The important part of the example is showing how it's quoted, so what's
in it could
On Fri, May 10, 2002 at 12:50:59PM -0700, Wayne Davison wrote:
> On Fri, 10 May 2002, terrell Larson wrote:
> > The [option-specifying form] of the -e option is not documented.
> > IMHO it should be.
>
> I agree. I've whipped up the following patch for rsync.yo, which I
> will commit to CVS in a
On Fri, 10 May 2002, terrell Larson wrote:
> If rsync is directed to copy a directory tree into another machine and
> the target directory does not exist then rsync will not create the
> required path
Dave Dykstra just recently responded to another user that this is the
intended behavior of rsync
I'm new to this list and I hope this is the proper way to submit a bug. If not then
please advise. Also I'm not a list subscriber so please email me directly and cc the
list if appropriate.
I beleive I have found a bug in rsync. It is reproducable and easy to confirm.
summary:
===
If r
That behavior is intentional. If you want to force it to create
parent directories you need to have a similar directory tree on the
source machine and use the --relative option, for example
rsync -a --relative local/bin B:/usr
- Dave
On Fri, Apr 26, 2002 at 12:52:20PM +0100, Ferguson, Dun
I have a server (A) with a directory structure I want to copy to another
server (/usr/local/bin...)
On the client (B), only /usr exists (/usr/local doesn't).
I used:
/opt/PKGrsync/bin/rsync -a --delete --force
--rsync-path=/opt/PKGrsync/bin/rsync --exclude=save -v -v /usr/local/bin
B:/usr/loca
37 matches
Mail list logo
