https://bugzilla.samba.org/show_bug.cgi?id=14390
--- Comment #4 from Wayne Davison ---
Thanks for the gentle prod to remind me about 14338. As things currently
stand, the master branch now has support for both zstd & lz4 compression.
--
You are receiving this mail because:
You are the QA Conta
https://bugzilla.samba.org/show_bug.cgi?id=14390
--- Comment #3 from Sebastian A. Siewior ---
(In reply to Wayne Davison from comment #2)
I've sent a zstd patch, what do you want me to do with it (#14338)?
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please u
https://bugzilla.samba.org/show_bug.cgi?id=14390
--- Comment #2 from Wayne Davison ---
I've updated the compression code to add a negotiation idiom like I did for
checksums, and then I re-enabled the external zlib's ability to handle both the
old-style compression (now named "
Davison ---
Yeah, the whole -zz idiom was not the best way to have implemented the
internal/external compression idiom. I'll look into what options we have to
make it better.
The best way to improve how rsync can interacts with an older rsync that is
using the internal zlib is to somehow fi
Just FYI, I decided to create a ticket on bugzilla to make the
tracking of the feature request more easy, I also used a more
descriptive title.
Bug 14390 - Feature request: don't fail if using "-z" transferring to
rsync complied with --with-included-zlib=no
https://bugzilla.samba.o
https://bugzilla.samba.org/show_bug.cgi?id=14390
Bug ID: 14390
Summary: Feature request: don't fail if using "-z" transferring
to rsync complied with --with-included-zlib=no
Product: rsync
Version: 3.1.3
Hello,
I'm one of the Debian maintainers of rsync and I'm currently
investigating the switch from "--with-included-zlib=yes" to "no" for
the next stable release (ETA 2021). So basically I'm investigating
what are the impacts of using upstream's zlib
On Wed, Mar 13, 2019 at 6:02 AM Christoph Gentsch via rsync <
rsync@lists.samba.org> wrote:
> I just had a look at the rysnc code (master branch) and realized, that
> there is a copy of the zlib included. So I checked if the CVEs from 2016
> are patched in this, and NOPE! they a
Hi,
I just had a look at the rysnc code (master branch) and realized, that
there is a copy of the zlib included. So I checked if the CVEs from 2016
are patched in this, and NOPE! they arent!
This means rsync still has those vulnerabilities of zlib in the current
release:
https://security
https://bugzilla.samba.org/show_bug.cgi?id=13707
Wayne Davison changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.samba.org/show_bug.cgi?id=13707
Bug ID: 13707
Summary: zlib/inflate.c:1528
Product: rsync
Version: 3.1.3
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P5
https://bugzilla.samba.org/show_bug.cgi?id=11215
--- Comment #2 from George ---
Anyone experiencing a similar issue may want to have a look at bug 10372 .
( Possibly related: bug 10332. )
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for m
https://bugzilla.samba.org/show_bug.cgi?id=11215
--- Comment #1 from Shevek ---
I think this bug is affecting us too, over multi-gigabyte files. There's one
specific file which is killing rsync, but it doesn't always kill it in the same
place.
--
You are receiving this mail because:
You are the
https://bugzilla.samba.org/show_bug.cgi?id=10677
Wayne Davison changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
https://bugzilla.samba.org/show_bug.cgi?id=11215
Bug ID: 11215
Summary: compression/zlib errors discard the zlib error message
Product: rsync
Version: 3.1.0
Hardware: All
OS: All
Status: NEW
Severity
https://bugzilla.samba.org/show_bug.cgi?id=10677
--- Comment #2 from Emanuel Haupt 2014-06-30 07:30:49 UTC
---
Sorry about the confusion, I should have been more clear. The FreeBSD version
is built with --with-included-zlib=no by default.
After reading the man page entry again about -z
Davison 2014-06-29 17:00:37 UTC ---
I tried to figure out what you think is broken, but I couldn't figure it out.
The -z option (as opposed to -zz) only works if you compile using the included
zlib, so use that if you want the backward-compatible -z functionality. Was
there something else? The
https://bugzilla.samba.org/show_bug.cgi?id=10677
Summary: external zlib broken after update to 3.1.1 on FreeBSD
Product: rsync
Version: 3.1.1
Platform: x64
OS/Version: FreeBSD
Status: NEW
Severity: normal
Priority
On Sat, Jun 14, 2014 at 6:21 AM, Mojca Miklavec wrote:
> but the configuration makes sure that "-I." comes first, while it doesn't
> make sure that the zlib include comes in front of the rest of the flags.
>
True. I moved both -Ipopt and -Izlib early in the CFLAGS
Hi,
I'm trying to compile rsync 3.1.1pre2 on OS X with CFLAGS=-I/opt/local/include.
The consequence of this is that rsync fails to build:
/usr/bin/clang -I. -I. -pipe -Os -I/opt/local/include -arch x86_64
-DHAVE_CONFIG_H -Wall -W -I./zlib -I/opt/local/include -c token.c -o
token.o
token.
https://bugzilla.samba.org/show_bug.cgi?id=6916
--- Comment #8 from Matt McCutchen 2011-12-26 01:43:02
UTC ---
(In reply to comment #7)
> 3.1.0 has a configure option --with-included-popt=no that can be used to get
> rsync to use the system's popt library.
That should say "
work fine.
There is going to be some new support for adding dictionary data during the
transfer in the official zlib code, but I haven't yet tested to see if using
this new support is identical to the rsync kluges or not. If it is, the rsync
code will eventually be updated to use the offici
receiver-side counterpart is the code in see_deflate_token in
token.c which inserts into the input stream a synthesized zlib-format block
containing the matched data.
The receiver-side behavior was possible to implement based on knowledge of the
zlib format without actually modifying zlib
stream is
willing to consider some changes in order to reach compromise. Could you please
contact them and try to discuss the situation, so it isn't necessary to bundle
modified zlib? Thanks
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving this mail
https://bugzilla.samba.org/show_bug.cgi?id=6916
--- Comment #4 from m...@mattmccutchen.net 2009-12-10 10:19 CST ---
The gzip enhancement bundled with rsync is Z_INSERT_ONLY, which lets rsync
enter matched blocks in the gzip history without transmitting them in the
compressed stream.
#3 from jzel...@redhat.com 2009-12-10 05:49 CST ---
Hi, I'm currently the maintainer of rsync in Fedora. As I was informed, zlib
upstream is willing to make some changes, so rsync doesn't need its bundled
version. But some discussion about this should take place first. To quote
https://bugzilla.samba.org/show_bug.cgi?id=6916
--- Comment #2 from m...@mattmccutchen.net 2009-11-27 23:57 CST ---
(In reply to comment #1)
> The only thing for rsync to potentially do is to have a build option for using
> a compatible, shared zlib.
What happened to, "
https://bugzilla.samba.org/show_bug.cgi?id=6916
--- Comment #1 from way...@samba.org 2009-11-25 19:54 CST ---
The only thing for rsync to potentially do is to have a build option for using
a compatible, shared zlib. The redhat bug has links to rsync's needed changes.
If f
https://bugzilla.samba.org/show_bug.cgi?id=6916
Summary: Avoid bundling a modified zlib
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P3
Component
On 10/12/06, thomas david clarke <[EMAIL PROTECTED]> wrote:
i would like a more detailed answer to a question.
{Z_INSERT_ONLY is used to update history}
How is this feature used in rsync?
My understanding is as follows; Wayne, please correct me as necessary.
Zlib compresses essentia
i would like a more detailed answer to a question.
{Z_INSERT_ONLY is used to update history}
How is this feature used in rsync?
Other than transfering less data, what other aplications might this feature
have?: https://webnetmail.port.ac.uk/w?aB.DDM.EK.UQJ-RugE.DCHEw.CbacuRQ.K
--
To unsubscrib
to include all the omitted unchanged data,
and this is a little too "chummy" with the zlib internals (someone
would need to add a new function to the zlib code to implement this
detail via a standard function if it were to be added to the official
zlib version). Tridge has mentioned to me t
Hello,
any news on integrating the rsync diff to libz in the upstream sources?
Does anyone of you, for the meantime, have a non-intrusive diff which
I can, as an operating system vendor, apply to our system libz, so that
rsync can be dynamically linked against it (configure might check for
a #def
https://bugzilla.samba.org/show_bug.cgi?id=3174
--- Additional Comments From [EMAIL PROTECTED] 2005-11-05 23:58 ---
I've tested the changes, which were actually very similar to my first pass at a
patch which we've been using for almost a year on production systems (rsyncing
live Oracl
https://bugzilla.samba.org/show_bug.cgi?id=3174
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|normal |enhancement
Status|ASSIGNED
https://bugzilla.samba.org/show_bug.cgi?id=3174
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Additional Comments
https://bugzilla.samba.org/show_bug.cgi?id=3174
[EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #1517 is|0 |1
obsolete|
https://bugzilla.samba.org/show_bug.cgi?id=3174
--- Additional Comments From [EMAIL PROTECTED] 2005-10-17 04:14 ---
Created an attachment (id=1517)
--> (https://bugzilla.samba.org/attachment.cgi?id=1517&action=view)
rsync compression level patch
--
Configure bugmail: https://bugzi
https://bugzilla.samba.org/show_bug.cgi?id=3174
Summary: Patch for specifying zlib compression level
Product: rsync
Version: 2.6.7
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
The zlib folks have clarified that version 1.1.4 is not vulnerable to
the latest zlib security problem, so all released versions of rsync are
not affected by the most recent security problem that was found in
version 1.2.2 (and also affects 1.2.1). So, there is now no rush to
release version
On Fri, Jul 08, 2005 at 02:10:19PM -0700, Wayne Davison wrote:
> [I neglected to cross-post this from the rsync-announce list to the
> regular rsync mailing list when I sent this out yesterday.]
>
> There has been some talk about a zlib security problem that could let
> someo
[I neglected to cross-post this from the rsync-announce list to the
regular rsync mailing list when I sent this out yesterday.]
There has been some talk about a zlib security problem that could let
someone overflow the buffers in the zlib decompression code, potentially
allowing someone to craft
Hi all-
My test results so far indicate a pretty decent improvement in overall rsync
performance when using a slightly more sophisticated checksum calculation.
The attached patch has the required changes (in hindsight, I should have
compressed this using zlib with the new algorithm
ficiency. The size of the compression block mask size has a second order
effect, but the effect is definitely there.
I'll be implementing the rsync checksum in the zlib algorithm next, to see if
going to really small window sizes improves the performance the way I think it
will.
Cheers,
Hey - when the stars align, they align :-)
Anyway, I've continued my testing (with a broader selection of files, and doing
a full zlib and rsync analysis), and I have some interesting results.
As would be expected, there is definitely a dependency of rsync performance
(i.e. "byt
On Sat, Feb 12, 2005 at 05:37:00PM -0700, Kevin Day wrote:
> I've been digging into the question of using rsync to sync up
> compressed data
Sounds like some nice research. I assume the Debian folks who are
maintaining the gzip package with the --rsyncable option would also be
interested in heari
he
output of the tests is the average compression block size, and the standard
deviation of the compression block size.
For the initial tests here (more follow!), this is run in a test harness that
just computes effective block sizes based on the two checksum algorithms - it
is NOT ru
file as an input file. The
output of the tests is the average compression block size, and the standard
deviation of the compression block size.
For the initial tests here (more follow!), this is run in a test harness that
just computes effective block sizes based on the two checksum algorithms - it
When using the -z and -B65536 options together, sometimes there is file
corruption. Client and server are both compiled against zlib 1.1.4, so
the gzip corruption shouldn't be there, right?
With -z and -B32768 there is an error, but it is detected in a different
way.
With -B65536 and wi
Dave Dykstra wrote:
> Actually, there was a problem in 2.5.3 that could likely have had that
> symptom; are you sure the remote side also has 2.5.4?
Ah! No - the remote side has not yet been upgraded to 2.5.4. I'll do the
upgrade and report if that fixes the problem.
Many thanks,
Victor Grey
On Thu, Mar 21, 2002 at 09:28:05AM -0600, Dave Dykstra wrote:
> On Mon, Mar 18, 2002 at 07:54:01AM -0800, Victor Grey wrote:
> > Using a fresh copy of rsync 2.5.4 installed from the ports collection on
> > FreeBSD 4.5 Release:
> >
> > Works fine unless I try to copy a large file with -avz, then
On Mon, Mar 18, 2002 at 07:54:01AM -0800, Victor Grey wrote:
> Using a fresh copy of rsync 2.5.4 installed from the ports collection on
> FreeBSD 4.5 Release:
>
> Works fine unless I try to copy a large file with -avz, then I get:
> rsync: connection unexpectedly closed (1377 bytes read so far)
Using a fresh copy of rsync 2.5.4 installed from the ports collection on
FreeBSD 4.5 Release:
Works fine unless I try to copy a large file with -avz, then I get:
rsync: connection unexpectedly closed (1377 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) at io.c(151)
On Tue, Mar 12, 2002 at 10:58:31AM +1100, Martin Pool wrote:
> It seems the patch we merged into rsync 2.5.3 is not correct and -z is
> not reliable. I'll do another release shortly.
So the extra ZFREE() in infblock.c was the culprit:
http://cvs.samba.org/cgi-bin/cvsweb
It seems the patch we merged into rsync 2.5.3 is not correct and -z is
not reliable. I'll do another release shortly.
--
Martin
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
I wrote:
> > Hopefully they will accept your patch and there will be a 1.1.4 release,
> > which also incorporates the infblock.c fixes. It would be bad to have
> > different (broken) versions of zlib out there when this can easily be
> > avoided.
http://www.gzip.org/zlib/
ill be a 1.1.4 release, which
> also incorporates the infblock.c fixes. It would be bad to have different
> (broken) versions of zlib out there when this can easily be avoided.
Yes, that would be good.
--
Martin
--
To unsubscribe or change options: http://lists.samba.org/mailma
n I generated the patch I sent to the list a while ago.
Hopefully they will accept your patch and there will be a 1.1.4 release, which
also incorporates the infblock.c fixes. It would be bad to have different
(broken) versions of zlib out there when this can easily be
On 5 Feb 2002, Jos Backus <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 06, 2002 at 02:30:51PM +1100, Martin Pool wrote:
> > rsync includes a slightly modified and incompatible version of zlib.
> > (PhD-project over-optimization...) To update to a newer zlib would
> > re
On 29 Jan 2002, Jos Backus <[EMAIL PROTECTED]> wrote:
> This patch (apologies for the size) updates zlib/* to the files that ship with
> zlib 1.1.3.
rsync includes a slightly modified and incompatible version of zlib.
(PhD-project over-optimization...) To update to a newer zlib w
This patch (apologies for the size) updates zlib/* to the files that ship with
zlib 1.1.3.
Index: zlib/ChangeLog
===
RCS file: /cvsroot/rsync/zlib/ChangeLog,v
retrieving revision 1.1
diff -u -r1.1 ChangeLog
--- zlib/ChangeLog 7
The following zlib files need patches in order to compile using Compaq C
on OpenVMS. These patches should also be needed on a Tru64 or LINUX on
ALPHA using Compaq C. These should work on any ANSI compliant compiler.
Operating System: OpenVMS ALPHA V7.3
Compiler: Compaq C T6.5
Compiler
62 matches
Mail list logo
