similar to: use_safe_inc_flist not set for 3.1.0 client -> 3.0.9 daemon

In debian bug #493559 (http://bugs.debian.org/493559) the problem is that when requesting a file from an older version rsync, the remote server gives an error: $ rsync rsync://rsync.blackholes.us/zones/countries/countries.rbl /tmp rsync: on remote machine: -: unknown option rsync error: requested action not supported (code 4) at clientserver.c(517) rsync: connection unexpectedly closed (4 bytes

hi. return value of close() (receiver.c) is ignored. when running out of quota on NFS (for example), this can happen (without the patch): output file(s) is/are truncated to 0 bytes and rsync reports success. with the fix, this happens: close "/home/luser/.test.mp3.PwaG50": Disc quota exceeded rsync error: error in file IO (code 11) at receiver.c(464) ... ...and additionally, test.mp3

Hi, I am maintaining a port of rsync (https://github.com/perlundq/yajsync) which is GPL:ed of course. The main purpose of the project is to provide a Java API library for the rsync protocol. It would therefore be really nice to be able to use LGPL as the license. But in order to do so I would first have to get a list of all the individual contributors to rsync and then be able to contact them

https://bugzilla.samba.org/show_bug.cgi?id=5075 Summary: Syncing with --iconv may yield protocol error Product: rsync Version: 3.0.0 Platform: All OS/Version: All Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: lennart.samba@lovstrand.com

diff --git a/clientserver.c b/clientserver.c index 2d7c28f..694a72d 100644 --- a/clientserver.c +++ b/clientserver.c @@ -806,6 +806,7 @@ static int rsync_module(int f_in, int f_out, int i, char *addr, char *host) exit_cleanup(RERR_UNSUPPORTED); } +#ifdef ICONV_OPTION if (!iconv_opt) { if (ic_send != (iconv_t)-1) { iconv_close(ic_send); @@ -816,6 +817,7 @@ static int

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> zstd compression was announced as "good compression with high throughput" so I gave it a try. With zlib, on high speed links the CPU is usually the bottle neck. With zstd I'm able to fill a 200Mbit link :) zstd detection happens automatically via pkg-config. No zstd header means no error about missing zstd. So that

Commit-ID: 527bee886ced0d22428417d60a638521e435bb96 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=527bee886ced0d22428417d60a638521e435bb96 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Wed, 30 May 2018 02:06:03 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: expand: Do not

In the past, I had restricted rsync so that the -e option was disallowed. As of rsync-3.0.0, I'm now seeing the following requests being made (on the server side): rsync --server -vlogDtprze.iL . I want to prevent '-e' as a client side option so arbitrary programs can't be executed. I found the following, but didn't trace through to verify exactly where I was in the code

This patch adds a switch --fat-filenames which replaces all characters that aren't legal on FAT filesystems with an underscore. This is the first time I touch the rsync code, so I may not be going about it the right way, but it seems to be working. Naturally there's some potential for collisions, but it's probably better than what happens currently (such files are simply not copied).

It seems latest rsync pass -e to the remote server to specify rsync client is a preversion (A thing I understand because -e works on all rsync version). However, this cause problems on server having options restriction, like denying -e because it allow to execute any command on it. So I suggest this patch to limit effect to unstable version of clients. WDYT ? Regards. Index: options.c

Commit-ID: 4bfffb1572c9d1b77538b5a3e92c27f91bd2ee99 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=4bfffb1572c9d1b77538b5a3e92c27f91bd2ee99 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Mon, 25 Feb 2019 14:00:31 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: expand: Fix

Hi, I recently encountered a problem with array subsetting and came up with a fix. Given an array of arbitrary dimensions, in which the number of dimensions is only known at runtime, I wanted to extract a subarray. The main issue with doing this is that in order to extract a subarray from an array of (say) 4 dimensions you usually specify something like this a.subarray <- a[,c(4,2),1:5,]

Commit-ID: 1285f79afbd9686c78c7815203ecbf3e87a81ff8 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=1285f79afbd9686c78c7815203ecbf3e87a81ff8 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Wed, 12 Sep 2018 14:27:16 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: expand: Fix

Am 07.01.2016 um 23:26 schrieb Per Lundqvist: > Hi, > > I am maintaining a port of rsync (https://github.com/perlundq/yajsync) > which is GPL:ed of course. The main purpose of the project is to > provide a Java API library for the rsync protocol. It would > therefore be really nice to be able to use LGPL as the license. > > But in order to do so I would first have to get a

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hy folks, everybody knows, that rsync eats up a lot of memory, when rsyncing a lot of files. To avoid this i run rsync on different parts of the directory-tree (e.g. first ~muchofileuser/muchofilesdir1 then ~muchofileuser/muchofilesdir2 and so on) and it works fine for me. So i tried to do this in a automatical way (e.g perl/shell/whatever

... > Getting the approval for a relicensing I think the contributions to > rsync have to be analyzed in detail to approach a reasonable number of > contributors. > > I experienced that finding a responsible person that is willing to > discuss such a case in an organization that contributed source code is > nearly impossible. > > Looking at the source code (my short

https://bugzilla.samba.org/show_bug.cgi?id=5012 Summary: iconv: client charset used by server process Product: rsync Version: 3.0.0 Platform: PPC OS/Version: Mac OS X Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: kaarle@web.de

Hi all, I recently ran into some problems with rsync. My plan is to renew some of our old administration concepts from early 90's, I already replaced rdist with rsync a few years ago. Because of the rdist legacy, the current method requires synchronizing files into 6 different locations, {/alt,/usr/alt}/{hostdep,sysdep,hutdep}, which in turn are prioritized by a tool that just symlinks

I was trying to use rsync to send files to a fileserver using an rssh restricted server. It refuses, saying that trying to override the shell with -e is forbidden. I didn't type "-e". When I look at the source, I see /* Checking the pre-negotiated value allows --protocol=29 override. */ if (protocol_version >= 30) { /* We make use of the -e

If rsync is called with -4 or -6, that option is currently ignored when ssh is used as the transport. The attached patch is a stab at passing the option on to the ssh process. It checks that the remote shell program is something that looks like ssh. Perhaps that could be done cleaner... Paul Slootman --- a/main.c 2008-03-01 21:01:41.000000000 +0100 +++ b/main.c 2008-03-04 18:55:10.933488013