On Tue, 2009-09-01 at 23:09 -0700, Wayne Davison wrote:
> The
> incompatible code was expunged from CVS and was never imported into git.
Two further remarks:
- You didn't expunge
http://rsync.samba.org/ftp/rsync/src/rsync-2.6.8.tar.gz .
- You could have saved me some head-scratching by redacting
On Tue, 2009-09-01 at 23:09 -0700, Wayne Davison wrote:
> On Wed, Sep 02, 2009 at 12:32:45AM -0400, Matt McCutchen wrote:
> > Why were they dropped from the development history? There doesn't
> > appear to be a copyright issue: the file bears a BSD license.
>
> It used a 3-clause BSD license, whi
On Wed, Sep 02, 2009 at 12:32:45AM -0400, Matt McCutchen wrote:
> Why were they dropped from the development history? There doesn't
> appear to be a copyright issue: the file bears a BSD license.
It used a 3-clause BSD license, which is incompatible with the GPL. The
incompatible code was expung
On Tue, 2009-09-01 at 14:11 +, Andrew Gideon wrote:
> On Mon, 31 Aug 2009 13:37:16 -0700, Wayne Davison wrote:
>
> >> Anyone knows a trick that the server only answer if the client is use
> >> the compression?
> >
> > This is not currently possible.
>
> What if rsync-path is set to a little
Wayne,
Today, to investigate an issue on RHEL 5.2, I checked out rsync 2.6.8
from the rsync repository and attempted to build it. The build failed
because the tagged tree did not contain lib/addrinfo.h, which is
included by rsync.h. On further investigation, the 2007-10-24 snapshot
of the CVS re
Jignesh Shah (jignesh.shah1...@gmail.com) wrote on 1 September 2009 22:17:
>Thanks Carlos.
>
>... rsync copy symlinks as symlinks
>What about the contents pointed by simlinks?
If they exist on the destination at the same place the symlink will
point to them, otherwise they'll dangling there (
https://bugzilla.samba.org/show_bug.cgi?id=6633
--- Comment #8 from way...@samba.org 2009-09-01 13:50 CST ---
Aha. The loop is being limited by buflen instead of sb.st_size. Change this:
- for (bufpos = 0; bufpos < buflen; ) {
- ssize_t cnt = rea
Hello list,
I'm running rsync from a FreeBSD 6.3 server to another FreeBSD 6.3
server. Both are running rsync 3.0.6. The transfer keeps dying with the
following errors.
On the receiver I'm getting the following error
2009/09/01 11:27:58 [23670] overflow: xflags=0x546 l1=0 l2=10376
lastname=
Thanks Carlos.
... rsync copy symlinks as symlinks
What about the contents pointed by simlinks?
Could you please also elaborate on "Only if it's inside source."
Thanks,
Jignesh
On Tue, Sep 1, 2009 at 8:25 PM, Carlos Carvalho wrote:
> Jignesh Shah (jignesh.shah1...@gmail.com) wrote on 1 Sept
Jignesh Shah (jignesh.shah1...@gmail.com) wrote on 1 September 2009 11:30:
>Hi, I have one question regarding handling of symlinks in rsync. If I have
>/source directory in which I have 100s of sub directories of directories and
>each one has symlink to some directories out side the /source dire
On Mon, 31 Aug 2009 13:37:16 -0700, Wayne Davison wrote:
>> Anyone knows a trick that the server only answer if the client is use
>> the compression?
>
> This is not currently possible.
What if rsync-path is set to a little script that only accepts the
connection (and exec()s the real rsync bin
Rsync shouldn't be converting UUID to uid/gid *for ACL entries*
(because Mac OS X stores those ACEs with a reference to a UUID, not a
uid/gid). For file ownership, etc., it should maintain its current
behavior.
On Aug 31, 2009, at 10:08 PM, Matt McCutchen wrote:
On Mon, 2009-08-31 at 16:
12 matches
Mail list logo
