H | 11 Feb 18:43 2016

Rsync options for reverse syncing

I am running the current version of rsync on Androic CM 11.2 and 12.1 on 
phones and tablets. While syncing to a server works fine, I am having 
problems with reverse syncing, specifically having the date and time set 
for files on the reverse sync.

Currently the flags are "rsync - vHrlt --chmod=Du+rwx, go-rwx, Fu+rw, 
go-rw --no-perms -e "ssh -y -p 22 -i '...'...* source destination" and 
the error message is "rsync: failed to set times on ... operation not 
permitted (1)". Since rsync is able to transfer the files, where lies 
the problem with setting times?

Thank you.

--

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

samba-bugs | 9 Feb 13:45 2016
Picon

[Bug 11726] New: --copy-links cause rsync to fail with ancestor symlink (..)

https://bugzilla.samba.org/show_bug.cgi?id=11726

            Bug ID: 11726
           Summary: --copy-links cause rsync to fail with ancestor symlink
                    (..)
           Product: rsync
           Version: 3.1.2
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P5
         Component: core
          Assignee: wayned <at> samba.org
          Reporter: cyphar <at> cyphar.com
        QA Contact: rsync-qa <at> samba.org

If you have a directory created like so:

% mkdir -p from/dir/
% ln -s .. from/dir/loop
% rsync -a --copy-links from to
rsync:
readlink_stat("/tmp/from/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop/dir/loop")
failed: Too many levels of symbolic links (40)
rsync error: some files/attrs were not transferred (see previous errors) (code
23) at main.c(1178) [sender=3.1.2]

For a trivial case of infinitely recursive symlinks (in other words when you go
through a symlink that takes you to an ancestor), rsync should just declare
(Continue reading)

Sam Holton | 8 Feb 21:33 2016
Picon

--link-dest not working on remote server (running daemon)

Hello,

I have read through the list of previous issues regarding this issue but haven't been able to resolve mine. I apologize in advance for the long text and am probably doing some simple typo. I have two servers in my setup:

Server 1
Doing rsync with --link-dest daily and working as expected. I'm getting the hard links in the new daily directories. 

Server 2
Running rsync daemon mode with following config

[offsite]
   path = /media/external/backup/
   comment = Offsite backup
   read only = no
   hosts allow = 192.168.2.0/24
   auth users = backup
   secrets file = /etc/rsyncd.scrt
   uid = 0
   gid = 0


My Goal
Server 1 has been running for several months now so it has several months of daily backups. I was able to do an initial sync to server 2 using -H option to keep my hardlink structure. That worked fine and my original plan was to just run the same rsync with -H after the daily backup was complete to keep both in sync. But that turned out to be very slow building the incremental file list as I'm guessing it scanned all files for each daily backup (even though they were hard lnked).

So my next plan was to just sync that latest daily backup from server 1 to server 2 and use the --link-dest option on server 2 to link it to the previous day.

The Problem
This is the command I'm troubleshooting right now

rsync -a -v -n -i --delete --link-dest=/backup-2016-02-01-0100 --password-file=/media/external/scripts/offsite_rsync.pass /media/external/backup/backup-2016-02-02-0100 backup <at> 192.168.2.102::offsite

It seems to be sending all files as new files (i.e. not picking up the link-dest option). I've tried using no slash at the beginning of link-dest, tried using ./ tried full path. etc.

Here is a snippet of the output from server 1 which is running the command:

<f+++++++++ backup-2016-02-02-0100/media/external/owncloud/data/sam/files/Photos/2007/20070120 DC Air and Space Museum/IMGP0906.JPG


On server 2 there is no backup-2016-02-02-0100 directory. However, the link-dest option I'm using has the file on server 2:

-rw------- 147 www-data www-data 4454193 Jan 20  2007 /media/external/backup/backup-2016-02-01-0100/media/external/owncloud/data/sam/files/Photos/2007/20070120 DC Air and Space Museum/IMGP0906.JPG

Output of same file from server 1

-rw------- 151 www-data www-data 4454193 Jan 20  2007 /media/external/backup/backup-2016-02-02-0100/media/external/owncloud/data/sam/files/Photos/2007/20070120 DC Air and Space Museum/IMGP0906.JPG


Troubleshooting
If I manually create the copy of server 2 first (cp -al backup-2016-02-01-0100 backup-2016-02-02-0100) and then run rsync without the --link-dest option I get the expected results. Only the files that changed or were removed/added are transferred.

Also I tried running the actual transfer without -n and it is indeed transferring all the old files.

Any help is appreciated.
--

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Angelos Ching | 8 Feb 15:21 2016
Picon

Bad description for --ignore-errors in man page

Hi there,

I was figuring out a way to copy as much files as possible off a corrupted file system using rsync, then I came across this —ignore-errors flag which is described on man page as:
If the sending side detects any I/O errors, then the deletion of any  files  at the destination will be automatically disabled. This is to prevent temporary filesystem failures (such as NFS errors) on the sending side causing a massive deletion of files on the destination. You can override this with the --ignore-errors option.

But then I came across a bug report on Debian’s tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181805

And I tested it personally, it makes rsync continue even when the underlying file system is encountering errors, copying whatever it can. Before I applied the flag, rsync just exit with error after copying a few files.

So maybe the man page can get some updates on what the flag —ignore-errors actually does and gives user clearer indication on the flag.

Best regards,
Angelos

--

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
jupiter | 4 Feb 02:33 2016
Picon

Is there a parameter in rsync to clean $BACKUPDIR before writing to it (--backup-dir=$BACKUPDIR)?

Hi,

I am runing rsync --backup --backup-dir=$BACKUPDIR where the BACKUPDIR=$(date +%d) to recycle the $BACKUPDIR in a month. But rsync does not clean the  $BACKUPDIR before writing to it in cycling.

I guess you have to clean it manually before the rsync can write to it. As my $BACKUPDIR is in remote machine, do you have to run ssh to delete it first before calling rsync in a script? Or if there is better parameter in rsync to automatically delete the old $BACKUPDIR, and create a new one?

Thank you.

- j
--

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
jupiter | 3 Feb 06:11 2016
Picon

How can the --backup-dir be set to remote machine?

Hi,

I am running rsync backup on Centos 6, the following command does not seem work, the /backup/fll_copy was fine, but the /backup/Wednesday in the remote machine was not created even I changed the source contents several times.


rsync -e "ssh -q -o StrictHostKeyChecking=no" --backup --backup-dir=username <at> ipaddress:/backup/$(date +%A) -av $SRC username <at> ipaddress:/backup/full_copy

Appreciate what I could be missing here?

Thank you.

Kind regards,

- j
--

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
samba-bugs | 29 Jan 21:45 2016
Picon

[Bug 11704] New: rsyncstats sorts dates wrong

https://bugzilla.samba.org/show_bug.cgi?id=11704

            Bug ID: 11704
           Summary: rsyncstats sorts dates wrong
           Product: rsync
           Version: 3.1.2
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayned <at> samba.org
          Reporter: bugzilla.samba.org <at> zengel.info
        QA Contact: rsync-qa <at> samba.org

rsyncstats show statistics with wrong date order:

TOTALS FOR SUMMARY PERIOD 2016/01/01 TO ***2016/01/21***

Daily Transmission Statistics

                 Number Of    Number of   Percent Of  Percent Of
     Date        Files Sent   MB  Sent    Files Sent  Bytes Sent
---------------  ----------  -----------  ----------  ----------
2016/01/01              570  10375.32866      0.12        0.69
2016/01/16              655  7317.213854      0.13        0.48
2016/01/24              495  5681.975908      0.10        0.38
2016/01/27            41125  101154.5519      8.46        6.70
2016/01/04            17075  62525.35909      3.51        4.14
2016/01/05            19870  65251.58114      4.09        4.32
2016/01/15            21620  65535.48440      4.45        4.34
2016/01/17              395  3713.043026      0.08        0.25
2016/01/02              360  4160.903625      0.07        0.28
2016/01/07            21565  84046.16057      4.43        5.57
2016/01/13            23450  75723.10462      4.82        5.02
2016/01/25            22150  89712.77994      4.55        5.94
2016/01/10              495  6874.872217      0.10        0.46
2016/01/26            34415  72377.36720      7.08        4.80
2016/01/03              600  7965.899901      0.12        0.53
2016/01/23             2140  10545.03610      0.44        0.70
2016/01/09              680  11327.12449      0.14        0.75
2016/01/28            22580  78863.89039      4.64        5.23
2016/01/08            20820  62567.35772      4.28        4.15
2016/01/11            29490  87068.98149      6.06        5.77
2016/01/12            25095  72422.45863      5.16        4.80
2016/01/22            30926  83395.29467      6.36        5.53
2016/01/06             2505  15280.35709      0.52        1.01
2016/01/18            30435  91414.26186      6.26        6.06
2016/01/19            36935  77847.47815      7.59        5.16
2016/01/20            27596  84001.79939      5.67        5.57
2016/01/14            25050  78379.55794      5.15        5.19
2016/01/21            27289  93731.06716      5.61        6.21

The problem is this:
sub datecompare {
    $a gt $b;
}

This function should return -1,0,1 and not true/false.

It should be:
sub datecompare {
    $a cmp $b;
}

because this is default sort rule you can change:
 <at> dates = sort datecompare keys %xferbytes;
to
 <at> dates = sort keys %xferbytes;

foreach $date (sort datecompare keys %xferbytes) {
to
foreach $date (sort keys %xferbytes) {

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

--

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

samba-bugs | 25 Jan 06:22 2016
Picon

[Bug 11692] New: Update config.guess and config.sub

https://bugzilla.samba.org/show_bug.cgi?id=11692

            Bug ID: 11692
           Summary: Update config.guess and config.sub
           Product: rsync
           Version: 3.1.2
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayned <at> samba.org
          Reporter: anton <at> samba.org
        QA Contact: rsync-qa <at> samba.org

Created attachment 11785
  --> https://bugzilla.samba.org/attachment.cgi?id=11785&action=edit
Update config.guess and config.sub

The current version of config.guess and config.sub is broken on powerpc64le.
The attached patch is just the result of:

wget -O config.guess \

"http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess"

wget -O config.sub \
  "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub"

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

--

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

f-rsync | 25 Jan 05:24 2016
Picon

Re: [Bug 11521] rsync does not use high-resolution timestamps to determine file differences

    > Date: Sun, 24 Jan 2016 15:43:20 -0800
    > From: Wayne Davison <wayne <at> thedavisons.net>

A couple questions below; please bear with me.

    > No, if you do a ext4 -> ext4 copy, rsync has set the matching ns info for
    > transferred files since 3.1.0. There was a case prior to rsync 3.1.2 where
    > a brand-new file transferred in the same second it was created wouldn't get
    > the right ns value because rsync was optimizing away the time-set if the
    > file's mod-time matched in the integer part (3.1.2 fixed that).

Oh, I see what happened.  My problem is that no Ubuntu LTS before
14.04 had rsync 3.1.0 or newer, and the original capability took more
than four years to make it into a released rsync version, if I'm
reading the release notes correctly.*  Unfortunately, that means
the vast majority of my machine base predates the fix, including the
machine hosting the backups.  I can obviously install newer rsyncs,
but that gives me a big installed base of pre-fix data that I'm going
to have to fix, and no more rsync security updates unless I track them
manually.  Yet I'd rather do this now, so I'm future-proofed, than
be badly surprised some years down the road when this rsync behavior
becomes the default, and to keep the problem from continuing to get worse.

* I may have tried 3.1.0 at some point and then realized the problems
  it'd give me for backups and didn't install it everywhere, pending
  a better fix; this is starting to ring bells.  I'm really surprised
  that the initial patch of Sep 7, 2009 never made it into a released
  rsync until 3.1.0 of Sep 28 2013; that's a four-year delay, and
  explains why I obviously never tried this out until perhaps an
  experiment with 3.1.0, and no doubt I didn't want to run a private
  version that wouldn't get security updates.  Ubuntu rsync versions:
  10.04 has 3.0.7 proto 30; 12.04 has 3.0.9 p 30; 14.04 has 3.1.0 p 31.)

So what it looks like is that the capability to transfer ns times at
all existed in CVS but not released since 2009, in released since
2013, and in an Ubuntu LTS since 2014.  And the current patch -seems-
to be an optimization that avoids -comparison- if the ns times match,
but that only affects speed---it doesn't change what gets written in
any event, just how fast.  Right?  But actually I think it changes
behavior besides that---see my test case below.

    > Beginning with this patch you can run rsync -aiv --checksum - <at> -1 and have
    > it fix the full mod-time on any matching files it finds. But for most newer
    > backups, the ns time will already be set correctly (as long as it was
    > created using a new enough rsync and protocol 31). If someone has a large
    > link-dest hierarchy that predates 3.1.0, then you could be sharing
    > hard-linked matching files from back before the ns info was included (the
    > older files would all have 0 for the ns value).

Wow, that -c really hurts.  If one wanted to live dangerously---with
the assumption that two files that otherwise match in all metadata
(including obviously length :) but whose timestamps differ in that one
has integer seconds and the other has the same integer seconds but
also nanoseconds, can rsync readjust the dates, without doing a full
checksum?  If not, I may write such a tool, or do it the (very) slow
way and have rsync re-checksum a few terabytes of my backups... :)
[Might find some bitrot that way, of course.]

Also, I actually -can't- use that command to fix my snapshots,
because (if I understand correctly), it will -alter- my existing
snapshots to match the -current- contents of files, destroying them
---I'll no longer be able to go back in time to a previous version.
I only want to update ns times on files in the older snapshots
if and only if changing integer times to ns times would be the
only modification.  I think rsync -ac - <at> -1 will do far more, yes?

As for - <at> -1, that introduces a surprising change in behavior when I
try it.  I'm unsure if it's intended, though I think it is.  But it
will -definitely- break my hardlinks and bloat the backups if I try
it without readjusting the dates in --link-dest directories (e.g.,
previous snapshots).  I find that specifying - <at> -1 copies the ns
timestamp from the source to the destination even if the --link-dest
directory has an integer timestamp, and so I assume this is part of
the purpose of the patch?  Not just an optimization, but a change in
the way --link-dest might work.  Observe:

22:57:22 ~$ mkdir T
22:57:25 ~$ cd T
22:57:26 ~/T$ mkdir 1 2 3 4 5 6
22:57:30 ~/T$ lat() { ls -alF -i --full-time "$ <at> "; }
22:57:49 ~/T$ touch 1/foo
22:57:53 ~/T$ ln 1/foo 1/bar
22:57:56 ~/T$ lat */*
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/bar
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/foo
22:57:59 ~/T$ rsync -aviH 1/ 2/
sending incremental file list
.d..t...... ./
>f+++++++++ foo
hf+++++++++ bar => foo

sent 139 bytes  received 53 bytes  384.00 bytes/sec
total size is 0  speedup is 0.00
22:58:13 ~/T$ lat */*
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/bar
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/foo
1321176 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 2/bar
1321176 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 2/foo
22:58:17 ~/T$ rsync -aviH --link-dest=../2 1/ 3/
sending incremental file list
.d..t...... ./

sent 89 bytes  received 19 bytes  216.00 bytes/sec
total size is 0  speedup is 0.00
22:59:05 ~/T$ lat */*
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/bar
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/foo
1321176 -rw-r--r-- 4 user user 0 2016-01-24 22:57:53.013689572 -0500 2/bar
1321176 -rw-r--r-- 4 user user 0 2016-01-24 22:57:53.013689572 -0500 2/foo
1321176 -rw-r--r-- 4 user user 0 2016-01-24 22:57:53.013689572 -0500 3/bar
1321176 -rw-r--r-- 4 user user 0 2016-01-24 22:57:53.013689572 -0500 3/foo
22:59:10 ~/T$ touch --date="2016-01-24 22:57:53 -0500" 2/bar
23:00:07 ~/T$ lat */*
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/bar
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/foo
1321176 -rw-r--r-- 4 user user 0 2016-01-24 22:57:53.000000000 -0500 2/bar
1321176 -rw-r--r-- 4 user user 0 2016-01-24 22:57:53.000000000 -0500 2/foo
1321176 -rw-r--r-- 4 user user 0 2016-01-24 22:57:53.000000000 -0500 3/bar
1321176 -rw-r--r-- 4 user user 0 2016-01-24 22:57:53.000000000 -0500 3/foo
23:00:09 ~/T$ rsync -aviH --link-dest=../2 1/ 4/
sending incremental file list
.d..t...... ./

sent 89 bytes  received 19 bytes  216.00 bytes/sec
total size is 0  speedup is 0.00
23:00:36 ~/T$ lat */*
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/bar
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/foo
1321176 -rw-r--r-- 6 user user 0 2016-01-24 22:57:53.000000000 -0500 2/bar
1321176 -rw-r--r-- 6 user user 0 2016-01-24 22:57:53.000000000 -0500 2/foo
1321176 -rw-r--r-- 6 user user 0 2016-01-24 22:57:53.000000000 -0500 3/bar
1321176 -rw-r--r-- 6 user user 0 2016-01-24 22:57:53.000000000 -0500 3/foo
1321176 -rw-r--r-- 6 user user 0 2016-01-24 22:57:53.000000000 -0500 4/bar
1321176 -rw-r--r-- 6 user user 0 2016-01-24 22:57:53.000000000 -0500 4/foo
23:00:38 ~/T$ ~/rsync-HEAD-20160124-1917GMT/rsync -aviH --link-dest ../2/ 1/ 5/
sending incremental file list
.d..t...... ./

sent 89 bytes  received 19 bytes  216.00 bytes/sec
total size is 0  speedup is 0.00
23:00:56 ~/T$ lat */*
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/bar
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/foo
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 2/bar
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 2/foo
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 3/bar
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 3/foo
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 4/bar
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 4/foo
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 5/bar
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 5/foo
23:00:59 ~/T$ ~/rsync-HEAD-20160124-1917GMT/rsync - <at> -1 -aviH --link-dest ../2/ 1/ 6/
sending incremental file list
.d..t...... ./
>f..t...... bar
hf+++++++++ foo => bar

sent 136 bytes  received 50 bytes  372.00 bytes/sec
total size is 0  speedup is 0.00
23:01:13 ~/T$ lat */*
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/bar
1321175 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 1/foo
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 2/bar
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 2/foo
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 3/bar
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 3/foo
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 4/bar
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 4/foo
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 5/bar
1321176 -rw-r--r-- 8 user user 0 2016-01-24 22:57:53.000000000 -0500 5/foo
1321177 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 6/bar
1321177 -rw-r--r-- 2 user user 0 2016-01-24 22:57:53.013689572 -0500 6/foo
23:01:16 ~/T$ rsync --version
rsync  version 3.1.0  protocol version 31
Copyright (C) 1996-2013 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes, prealloc

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.
23:07:25 ~/T$ ~/rsync-HEAD-20160124-1917GMT/rsync --version
rsync  version 3.1.3dev  protocol version 31
Copyright (C) 1996-2015 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, no ACLs, xattrs, iconv, symtimes, prealloc

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.
23:07:32 ~/T$ cat /etc/issue
Ubuntu 14.04.3 LTS \n \l

23:08:21 ~/T$

--

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Per Lundqvist | 24 Jan 12:09 2016
Picon

Re: LGPL relicense port of rsync

Hi Martin,

2016-01-23 18:41 GMT+01:00 Martin Pool <mbp <at> sourcefrog.net>:
> It seems like yajsync is a reimplementation of rsync's protocol by looking
> at the GPL'd C rsync source, but it doesn't actually include any code from
> rsync. Is that right?

Yes correct, it is a complete rewrite in Java. Most of it is
completely different, only some small parts of the actual code is
actually similar to the original.

> In that case I think the yajsync authors are welcome to use whatever licence
> they think fit.
>
> If it was a line-by-line translation or a mere obfuscation of the existing
> code that might be different.

OK, but I am hesitant about this anyway, but I might very well be wrong.

>
> I don't consider the protocol copyrighted or restricted by the GPL.

Agreed, the protocol is not copyrighted but the code is, and the code
the only specification there is at the moment.

> As for why am I not on this list? It's been a long time! I just got
> interested in other things.

Thanks for input!

--
Per Lundqvist

--

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Mike McCracken | 21 Jan 22:59 2016
Gravatar

Can I help move bug 11521 along?

Hi, I filed bug 11521 [1] back in August, and I can't tell if anyone's looked at it.

It is a pretty rare, but easy to understand problem, with (I think) a straightforward fix.

I included a reproducer script and a patch that worked well for me, but as this is the first time I've looked at the rsync code base I wouldn't be too surprised if I'd missed some portability implications or the like.

I was wondering if there's anything further I could do to help.

Thanks,
-mike

[1]: https://bugzilla.samba.org/show_bug.cgi?id=11521
--

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Gmane