Re: Rsync 3.2.3pre1 released

> On 28 Jul 2020, at 20:53, Nelson H. F. Beebe via rsync > wrote: > > To my surprise, ALL of the builds failed, and examination of the build > logs showed they were all due to missing libraries or header files, > notably for one or more of lz4, openssl, xxhash, and zstd. Once I > installed

Re: [PATCH] SSE2/SSSE3 optimized version of get_checksum1() for x86-64

> On 18 May 2020, at 19:02, Jorrit Jongma wrote: > > I think you're missing a point here. Two different checksum algorithms > are used in concert, the Adler-based one and the MD5 one. I > SSE-optimized the Adler-based one. The Adler-based hash is used to > _find_ blocks that might have shifted,

Re: [PATCH] SSE2/SSSE3 optimized version of get_checksum1() for x86-64

Thank you Jorrit for your detailed answer. > On 18 May 2020, at 17:58, Jorrit Jongma via rsync > wrote: > > Well, don't get too excited, get_checksum1() (the function optimized > here) is not the great performance limiter in this case, it's > get_checksum2() and sum_update(), which will be

Re: Enabling easier contributions to rsync

> On 26 Apr 2020, at 20:37, Filipe Maia via rsync wrote: > > Hi, > > Are there plans to soon move to github or some other place where people can > easily contribute to rsync, making the software discussion more lively and > productive? > I've seen several useful patches being submitted (e.g.

Re: --link-dest. Time to 'building file list' incrementing

Hi, As you are on Cygwin, you should consider the notexec & noacl mount options : https://cygwin.com/cygwin-ug-net/using.html#mount-table They impact stat() performance. Ben > On 8 Jan 2019, at 10:56, John Simpson via rsync wrote: >

Re: rsync of a reflink from OCFS2

the remote file over the network in order to do the diff then it would write the whole file over the network anyway (--inplace would help a little). Local copies force --whole-file for a good reason. On 03/14/2018 10:05 AM, Ben RUBSON via rsync wrote: On 14 Mar 2018, Lentes, Bernd via rsync wrote

Re: rsync of a reflink from OCFS2

On 14 Mar 2018, Lentes, Bernd via rsync wrote: - On Mar 14, 2018, at 2:19 PM, Ben RUBSON ben.rub...@gmail.com wrote: On 14 Mar 2018, Lentes, Bernd via rsync wrote: I would now expect a rsync from the snap would transfer just some megay bytes to the file from the day before. But it

Re: rsync of a reflink from OCFS2

On 14 Mar 2018, Lentes, Bernd via rsync wrote: I would now expect a rsync from the snap would transfer just some megay bytes to the file from the day before. But it doesn't: ha-idg-1:/cluster/guests/servers_alive # time rsync -av --stats sa.raw.snap

Re: Rsync and client-side encryption of files

On 11 Jan 2018 03:29, H via rsync wrote: Is anyone using client-side encryption of files before transferring them to a cloud server using Rsync? I am running CentOS.-- A solution could be EncFS in reverse mode. Ben -- Please use reply-all for most replies to avoid omitting the mailing

Re: rsync does hours of "fake-work" after failure

> On 06 Oct 2017, at 13:18, Frank Steiner wrote: > > Ben RUBSON wrote >> >> I encountered same issue and proposed the following patch : >> https://bugzilla.samba.org/show_bug.cgi?id=12525 > > Sorry, I really missed that as my search keywords were completely >

Re: rsync does hours of "fake-work" after failure

> On 06 Oct 2017, at 12:24, Frank Steiner via rsync > wrote: > > Hi, > > I just stepped on a strange and very annoying bug in rsync-3.1.0 as > shipped with SuSE Linux Enterprise 12, but verified the bug also > with rsync-HEAD-20170123. > > I tried to copy some of my

Re: [Bug 12819] [PATCH] sync() on receiving side for data consistency

> On 15 Jun 2017, at 19:29, Karl O. Pinc via rsync > wrote: > > On Thu, 15 Jun 2017 13:23:44 + > just subscribed for rsync-qa from bugzilla via rsync > wrote: > >> https://bugzilla.samba.org/show_bug.cgi?id=12819 >> >> --- Comment #7 from