similar to: rsync --server -e VERSION issue

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

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

Dear collegaues, please evaluate the patch attached, which allow to use both --detect-renamed and --fileflags extra features. This is meta-patch which sould be applied to detect-renamed. fileflags patch should be applied first, following by the modified detect-renamed patch. It is included in current FreeBSD port, but it seems it would be much more useful to be supported by samba

Hi, When using the latest rsync 3.1.0 client, connecting to a pre 3.1.0 (i.e. 3.0.9 and earlier, protocol version 30) server running in daemon mode and requesting a recursive (incremental by default) file transfer, the variable use_safe_inc_flist is not set (affecting how I/O errors are handled during file list generation). so it is set for: 3.0.9 client -> 3.0.9 daemon 3.0.9 client ->

I posted a patch a few days ago that adds copying of atime. At that time, it was just enabled with -t/--times. After some time, we have figured out that that choice might not have been the best. Here's a new version of the patch (relative to CVS) that adds -A/--copy-atime instead. It also includes a test case. Any feedback on this patch and/or the previous one that I posted?

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

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 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

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

This is a PoC patch for NFSv4/ZFS ACLs. The objective of the patch is that rsync --acls support NFSv4/ZFS ACLs without requiring a new command line option NFSv4 ACLs can't be represented using POSIX draft ACLs, if an NFSv4 ACL is present a separate POSIX draft ACL will not be present and there are new APIs to access NFSv4 ACLs. So we need to distinguish between NFSv4 ACLs and POSIX ACLs in

I just took a look at the 2.5.5 codebase to see how easy it would be to write a little driver script that downloads a big directory tree from an rsync daemon the chunky way (get a list of a module's subdirectories and do the transfer by subdirectory). The reason for doing this is obvious when you have large directory trees, as is the case for many of us. Unfortunately the way list_only is

Hello, I need to run rsync on a mac (OS X 10.6.5) with the --detect-renamed option available. I therefore started to compile rsync with the 3 relevant patches (in my opinion) : - fileflags.diff - crtimes.diff - detect-renamed.diff Here are my exact compile instructions : patch -p1 <patches/fileflags.diff patch -p1 <patches/crtimes.diff patch -p1 <patches/detect-renamed.diff

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,]

Hi, first of all, sorry for taking so long. Unfortunately, some other tasks kept coming up. Anyway, attached is the version of the flags patch, that is based on the one I'm using with 2.6.9. It is against the rsync-3.0.0pre9 release. I've included the option name change from the repository, so the option is now called --fileflags. Improved from the previously distributed version is the

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

Hi, One feature missing from rsync, and requested on this list before, is on-the-fly conversion of filename character encoding. For example, I often need to sync files having Hebrew filenames from a UTF-8 system (Linux) to an ISO8859-8 system (Cygwin on Windows 2000 using the non-Unicode Win32 interface). Other circumstances surely abound. Attached is a patch against rsync 2.6.2 that adds an

-----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

Currently rsync has a bit of a problem with very large files. Dynamic block sizes were introduced to try handle that automatically if the user didn't specify a block size. Unfortunately that isn't enough and the block size would need to grow faster than the file. Besides, overly large block sizes mean large amounts of data need to be copied even for small changes. The maths indicate

Dear all, Paulo Ribeiro, p.ribeiro@lancaster.ac.uk, and myself noticed that R sometimes breaks down with a segmentation fault of (at least for us) unknown course. (We've read #411 and #671 in the bug report on "optim" -- the problem described there sounds familiar; but we have not found any hint on a segmentation fault.) Please find at the very end of this email the file