[Bug 13526] New: Hard link creation time

https://bugzilla.samba.org/show_bug.cgi?id=13526 Bug ID: 13526 Summary: Hard link creation time Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5

[Bug 11215] compression/zlib errors discard the zlib error message

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

[Bug 10332] sync won't talk to rsync-3.1.0

https://bugzilla.samba.org/show_bug.cgi?id=10332 --- Comment #4 from George --- Had a similar issue with rsync 3.1.0 on the server, building 3.1.1 with internal lib solved the problem; therefore -- could indeed be a dup of bug 10372. -- You are receiving this mail

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #20 from Dave Gordon --- So, looking like a ZFS issue but triggered in some way by the specific behaviour of rsync (e.g. writing a certain block size/pattern causes the quota error to be lost). The truss listing from a

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #21 from Dave Gordon --- Created attachment 14019 --> https://bugzilla.samba.org/attachment.cgi?id=14019=edit Test patch to see whether fdatasync() or fsync() detects a write failure -- You are receiving this mail

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #22 from Dave Gordon --- (In reply to Ben RUBSON from comment #19) Just to be totally certain about what ZFS may or may not share between files, could you try this variant of your testcase: # zfs destroy $z # zfs

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #19 from Ben RUBSON --- I managed to reproduce the issue on 11.0-RELEASE-p16. Below a simple test case, without compression, without deduplication. Note that issue is reproductible with quota, but not with

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #23 from Dave Gordon --- Looks like this ZFS problem could be a FreeBSD-specific issue; one of the commits mentioned in this FreeNAS bug report has the subject zfs_write: fix problem with writes appearing to succeed

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #26 from Rui DeSousa --- (In reply to Ben RUBSON from comment #25) That is awesome. Thanks you for all of your efforts! -- You are receiving this mail because: You are the QA Contact for the bug. -- Please

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #24 from Ben RUBSON --- ZFS only shares between files with dedup on. So first rsync / diff succeeded, second gave same result as before : # rsync -a --inplace $tmpfs/f1 $f/f3 ; echo $? ; diff $tmpfs/f1 $f/f3 0

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #28 from Dave Gordon --- (In reply to Carson Gaspar from comment #27) Hmm? If you're referring to line 810 of io.c, which is the only write(2) call I can see in perform_io(), in the current HEAD it looks like this:

[Bug 13321] Rsync --copy-dest issue

https://bugzilla.samba.org/show_bug.cgi?id=13321 --- Comment #2 from Dave Gordon --- Looks right :) Another way to say it would be using a relative path: $ rsync -rlDi -z -t --no-h --out-format="%t %i %n %L" --stats --chmod=Du=rwx,Dgo=rx,Fu=rw,Fgo=r --delay-updates --partial

[Bug 13266] Writing of files to Apple's new "AP" controller model SSD's takes 4x longer.

https://bugzilla.samba.org/show_bug.cgi?id=13266 --- Comment #5 from Chris Tipper --- I think I ought to report that the problem has resolved itself on my setup, I didn't change anything but after the initial sync it returned to previous throughput. I am using the

[Bug 13266] Writing of files to Apple's new "AP" controller model SSD's takes 4x longer.

https://bugzilla.samba.org/show_bug.cgi?id=13266 --- Comment #6 from Daniel Shepherd --- Respectfully Chris you didn't have this specific bug, as I said it only affects AP controllers. Whatever you were experiencing has nothing to do with this. I've verified the AP controller

[Bug 13241] A problem with test for xattrs transfer

https://bugzilla.samba.org/show_bug.cgi?id=13241 Dave Gordon changed: What|Removed |Added CC||dg32...@zoho.eu ---

[Bug 10357] make check fails for xattr tests

https://bugzilla.samba.org/show_bug.cgi?id=10357 Dave Gordon changed: What|Removed |Added CC||dg32...@zoho.eu ---

[Bug 12820] rsync always try change owner and group of symlink in --fake-super mode

https://bugzilla.samba.org/show_bug.cgi?id=12820 --- Comment #1 from Dave Gordon --- (In reply to Pavel Alexeev from comment #0) The listing at the end of your report is presumably on the sending side; on the receiver, you should see that the transfer has converted the symlink

[Bug 13241] A problem with test for xattrs transfer

https://bugzilla.samba.org/show_bug.cgi?id=13241 --- Comment #2 from Michal Ruprich --- Thanks for the answer Dave, I filed this bug a few days before the 3.1.3 version came out. I was trying the make check with 3.1.2 release and there it was failing. With the new version

[Bug 7249] Add an option to use O_NOATIME

https://bugzilla.samba.org/show_bug.cgi?id=7249 --- Comment #9 from Michal Ruprich --- Did any of you who uses rsync with noatime patch had problems with running 'make check' command? It seems to me that some of the source files might be compiling in different order than

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #17 from Rui DeSousa --- (In reply to Dave Gordon from comment #14) Here's the output you requested. ZFS would use the same block even if it's the same data as don't have dedup enabled. [postgres@hades ~]$ ls

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #18 from Rui DeSousa --- I also wrote a little util as well; I get the correct error in write spot. [postgres@hades ~]$ cat 0001005E0017 | ./fwrite/fwrite arch/0001005E0017 fwrite:

[Bug 13321] Rsync --copy-dest issue

https://bugzilla.samba.org/show_bug.cgi?id=13321 --- Comment #1 from Anatoly Penkov --- rsync -rlDi -z -t --no-h --out-format="%t %i %n %L" --copy-dest=/data/cache --stats --chmod=Du=rwx,Dgo=rx,Fu=rw,Fgo=r --delay-updates --partial --delete-after --force

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #16 from Rui DeSousa --- (In reply to Ben RUBSON from comment #15) I just set the quota property. NAME PROPERTY VALUE SOURCE hydra/home/postgres/arch quota 1G

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #27 from Carson Gaspar --- (In reply to Dave Gordon from comment #23) Reading this, I took a look at the rsync sources, and, indeed, rsync has a bug. perform_io() does not correctly check the return code from

[Bug 13321] New: Rsync --copy-dest issue

https://bugzilla.samba.org/show_bug.cgi?id=13321 Bug ID: 13321 Summary: Rsync --copy-dest issue Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #1 from Marc Krämer --- I'd like to point out that this change is a changed behavior that breaks some scripts depending on this behavior. Can you consider to change it to the original behavior, or add a new

[Bug 13239] "rsync --times" does not keep dirs' setgid bits when user not member of setgid group

https://bugzilla.samba.org/show_bug.cgi?id=13239 --- Comment #1 from Dave Gordon --- Root cause here is that in some modes rsync will create a directory first, then later go back and fix up its modes. This is necessary if (for example) the final modes prevent writing by the

[Bug 13364] rsyncd clips trims relative symlinks outside of source tree

https://bugzilla.samba.org/show_bug.cgi?id=13364 --- Comment #1 from Dave Gordon --- Comment on attachment 14099 --> https://bugzilla.samba.org/attachment.cgi?id=14099 setup instructions and copier This is a documented feature; see rsyncd.conf(5): munge_symlinks ...

[Bug 13364] rsyncd clips trims relative symlinks outside of source tree

https://bugzilla.samba.org/show_bug.cgi?id=13364 --- Comment #2 from Dave Gordon --- Comment on attachment 14099 --> https://bugzilla.samba.org/attachment.cgi?id=14099 setup instructions and copier Having set up an rsync daemon (on localhost:10873): $ # Initial fetch of

[Bug 13385] rsync sometimes silently transfers more or fewer mtimes than it should

https://bugzilla.samba.org/show_bug.cgi?id=13385 --- Comment #1 from Silvan Schmitz --- Oops, I copy-pasted incorrectly and forgot the --size-only for the second test case -- as I wrote it, both rsync's output and the result will be different. Here's what I should have

[Bug 13385] New: rsync sometimes silently transfers more or fewer mtimes than it should

https://bugzilla.samba.org/show_bug.cgi?id=13385 Bug ID: 13385 Summary: rsync sometimes silently transfers more or fewer mtimes than it should Product: rsync Version: 3.1.3 Hardware: All OS: Linux

[Bug 13364] rsyncd clips trims relative symlinks outside of source tree

https://bugzilla.samba.org/show_bug.cgi?id=13364 --- Comment #3 from Chris Severance --- >enable munge-symlinks. That way the client will get back the same out-of-tree >symlink as it started with This is a lousy option for backups. The only way to get my

[Bug 13388] New: Feature request: When deleting files only delete files that are over a certain age.

https://bugzilla.samba.org/show_bug.cgi?id=13388 Bug ID: 13388 Summary: Feature request: When deleting files only delete files that are over a certain age. Product: rsync Version: 3.1.3 Hardware: All OS:

[Bug 5478] rsync: writefd_unbuffered failed to write 4092 bytes [sender]: Broken pipe (32)

https://bugzilla.samba.org/show_bug.cgi?id=5478 --- Comment #34 from David Nelson --- FYI. Although when rsync ver. 3.0.9 is called in Ubuntu 12.04LTS to "push" files to the server, e.g., rsync / server::Backups/ it fails with the error: rsync error: error in rsync

[Bug 13385] rsync sometimes silently transfers more or fewer mtimes than it should

https://bugzilla.samba.org/show_bug.cgi?id=13385 --- Comment #2 from Silvan Schmitz --- Links also don't work ... $ mkdir a b $ ln -s / a/link $ ln -s / b/link $ touch -hd "2018-04-16 10:00:00.123" a/link $ touch -hd "2018-04-16 10:00:00.456" b/link $ stat --format "%n:

[Bug 13268] [WARN] shifting a negative signed value is undefined

https://bugzilla.samba.org/show_bug.cgi?id=13268 --- Comment #2 from Ben RUBSON --- Many thanks Wayne ! -- 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

[Bug 13364] New: rsyncd clips trims relative symlinks outside of source tree

https://bugzilla.samba.org/show_bug.cgi?id=13364 Bug ID: 13364 Summary: rsyncd clips trims relative symlinks outside of source tree Product: rsync Version: 3.1.3 Hardware: x64 OS: Linux Status:

[Bug 13268] [WARN] shifting a negative signed value is undefined

https://bugzilla.samba.org/show_bug.cgi?id=13268 Wayne Davison changed: What|Removed |Added Resolution|--- |FIXED

[Bug 8682] Skip current transfer keyboard function

https://bugzilla.samba.org/show_bug.cgi?id=8682 --- Comment #4 from Christian Kujau --- If this ever gets implemented: instead of (interactively) pressing a key to interrupt the current transfer of a particular object, I'd like it to also react to a signal (e.g. SIGUSR1)

[Bug 13320] file contents cause rsync to fail (with certains args and dir structure)

https://bugzilla.samba.org/show_bug.cgi?id=13320 --- Comment #1 from Dave Gordon --- Bug will be triggered if: options include both --sparse and --preallocate, AND the second (or subsequent) file to be copied begins with one or more zero bytes. .Dave. -- You are receiving

[Bug 13320] file contents cause rsync to fail (with certains args and dir structure)

https://bugzilla.samba.org/show_bug.cgi?id=13320 --- Comment #3 from Dave Gordon --- Problem introduced by commit f3873b3d88b61167b106e7b9227a20147f8f6197 Author: Wayne Davison Date: Mon Oct 10 11:49:50 2016 -0700 Support --sparse combined

[Bug 13320] file contents cause rsync to fail (with certains args and dir structure)

https://bugzilla.samba.org/show_bug.cgi?id=13320 --- Comment #2 from Dave Gordon --- Created attachment 14018 --> https://bugzilla.samba.org/attachment.cgi?id=14018=edit Simple although probably suboptimal fix -- You are receiving this mail because: You are the QA Contact

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #5 from Rui DeSousa --- (In reply to Dave Gordon from comment #4) Hi Dave, I'm not seeing any errors on the write calls. Would an fsync() be required to force the error? [postgres@hades ~]$ grep ERR

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #3 from Dave Gordon --- (In reply to Rui DeSousa from comment #2) Here's a snippet from Oracle's ZFS help ... https://docs.oracle.com/cd/E19253-01/819-5461/gitfx/index.html "Enforcement of user and group quotas might

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #4 from Dave Gordon --- To see whether rsync is getting any errors reported by any system calls it makes, one could run it under strace(1) on Linux, or dtrace on Solaris. Presumably FreeBSD has at least one of these,

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #1 from Kevin Korb --- Are you saying that it is exiting with an exit code of 0 after outputting that error or that sometimes in the same condition it shows no error and exits code 0? Either way it would probably

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #2 from Rui DeSousa --- (In reply to Kevin Korb from comment #1) I saying that in some cases the rename does not fail; and in those cases it returns success despite there not being enough space to store the

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #12 from Rui DeSousa --- (In reply to Dave Gordon from comment #10) The sparse option errors out :). [postgres@hades ~]$ rsync -av --sparse 0001005E0017 arch/0001005E0017 sending

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #6 from Rui DeSousa --- (In reply to Rui DeSousa from comment #5) It looks like no error is returned and result is a sparse file. I think a sync() would be required otherwise the file is truncated on close to

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #9 from Dave Gordon --- (In reply to Rui DeSousa from comment #6) In your example: $ rsync -av --inplace 0001005E0017 arch/0001005E0017 sending incremental file list 0001005E0017

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #13 from Rui DeSousa --- (In reply to Rui DeSousa from comment #12) Running truss on the --sparse option does show the error being is returned during the write call. [postgres@hades ~]$ truss -f -o sparse.log

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #10 from Dave Gordon --- BTW, have you tried *either* --sparse *or* --preallocate (but not both together, please, as that will trigger bug 13320 - https://bugzilla.samba.org/show_bug.cgi?id=13320) Does you get the

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #11 from Rui DeSousa --- (In reply to Dave Gordon from comment #7) This is the result of hard link on the temp file where the rename failed. root@hades:~postgres/arch # ls -lh rsync.temp ; du -h rsync.temp

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #8 from Ben RUBSON --- (In reply to Dave Gordon from comment #3) > ZFS probably notices the quota problem somewhere between (b) and (c), drops > the excess data, and returns EDQUOT to the close(2) call. (In

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #7 from Dave Gordon --- (In reply to Rui DeSousa from comment #5) That was a run where the rename failed. Do you know whether the temporary file was truncated or corrupted in that scenario? [HINT: one can stop the

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #14 from Dave Gordon --- (In reply to Rui DeSousa from comment #6) So you now have an example which reliably produces a bad outcome (corrupted file)? With the combination of (a) insufficient space before copying, and

[Bug 13317] rsync returns success when target filesystem is full

https://bugzilla.samba.org/show_bug.cgi?id=13317 --- Comment #15 from Ben RUBSON --- Rui just to be sure, which type of ZFS quota are you using ? quota ? refquota ? userquota ? -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use

[Bug 13492] New: report modified dir when using iconv

https://bugzilla.samba.org/show_bug.cgi?id=13492 Bug ID: 13492 Summary: report modified dir when using iconv Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal

[Bug 13496] lseek returned -1, not 2147483648: Invalid argument (22)

https://bugzilla.samba.org/show_bug.cgi?id=13496 --- Comment #1 from Peter Koch --- (In reply to Peter Koch from comment #0) Our Sun Solaris 10 machine is a 64bit system but our gcc compiler creates 32bit executables if not told otherwise root@v480# file /usr/bin/rsync /usr/bin/rsync: ELF

[Bug 13496] New: lseek returned -1, not 2147483648: Invalid argument (22)

https://bugzilla.samba.org/show_bug.cgi?id=13496 Bug ID: 13496 Summary: lseek returned -1, not 2147483648: Invalid argument (22) Product: rsync Version: 3.1.2 Hardware: Sparc OS: Solaris Status:

[Bug 13645] New: Improve efficiency when resuming transfer of large files

https://bugzilla.samba.org/show_bug.cgi?id=13645 Bug ID: 13645 Summary: Improve efficiency when resuming transfer of large files Product: rsync Version: 3.0.9 Hardware: All OS: All Status: NEW

[Bug 13645] Improve efficiency when resuming transfer of large files

https://bugzilla.samba.org/show_bug.cgi?id=13645 --- Comment #1 from Kevin Korb --- If you are sure the file has not been changed since it was partially copied, see --append. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies

[Bug 13645] Improve efficiency when resuming transfer of large files

https://bugzilla.samba.org/show_bug.cgi?id=13645 --- Comment #2 from Rob Janssen --- Thanks, that helps a lot for this particular use case. (the files are backups) -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies to avoid

[Bug 5124] Parallelize the rsync run using multiple threads and/or connections

https://bugzilla.samba.org/show_bug.cgi?id=5124 --- Comment #7 from Luiz Angelo Daros de Luca --- I also vote for this feature. Using multiple connections, rsync can use multiples internet connections at the same time. -- You are receiving this mail because: You are the QA Contact for the bug.

[Bug 13656] New: --link-dest target with symbolic links from different user produces unnecessary error

https://bugzilla.samba.org/show_bug.cgi?id=13656 Bug ID: 13656 Summary: --link-dest target with symbolic links from different user produces unnecessary error Product: rsync Version: 3.1.3 Hardware: All OS:

[Bug 7004] Use posix_fadvise to free cached file contents when done

https://bugzilla.samba.org/show_bug.cgi?id=7004 --- Comment #3 from Arkadiusz Miskiewicz --- The rsync filling up kernel cache is a problem on bigger backup servers. These days POSIX_FADV_DONTNEED is commonly implemented in unix systems. Anyway as temporary/not optimal workaround:

[Bug 13660] New: State clearly in manpage that --append-verify is an edge-case

https://bugzilla.samba.org/show_bug.cgi?id=13660 Bug ID: 13660 Summary: State clearly in manpage that --append-verify is an edge-case Product: rsync Version: 3.1.3 Hardware: All OS: All Status:

[Bug 11879] escape rrsync restricted folder

https://bugzilla.samba.org/show_bug.cgi?id=11879 Nick Cleaton changed: What|Removed |Added CC||n...@cleaton.net --- Comment #2 from Nick

[Bug 11879] escape rrsync restricted folder

https://bugzilla.samba.org/show_bug.cgi?id=11879 Nick Cleaton changed: What|Removed |Added Attachment #14658|0 |1 is obsolete|

[Bug 11879] escape rrsync restricted folder

https://bugzilla.samba.org/show_bug.cgi?id=11879 Nick Cleaton changed: What|Removed |Added Attachment #14648|0 |1 is obsolete|

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #8 from Marc Krämer --- @Axel: you're right. This is not what we want. Even the output sync warning: some files vanished before they could be transferred is not desireable if the parameter is called "ignore" there should not be any

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #9 from Axel Kittenberger --- @Marc, indeed. I'm the author of Lsyncd. https://github.com/axkibe/lsyncd If this could work properly, it would simplify things a lot, also improve perfomance a good deal. Due to this bug I had to drop

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #10 from Marc Krämer --- @Axel: cool, I've played a bit with your tool, but for my needs with many directories inotify was the pitfall. I'm coauthor on sfs (https://github.com/mokraemer/sfs) which uses fuse for signaling. And then, as

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #7 from Axel Kittenberger --- No please don't close. Still not the behavior I'd expect: """ ~$ mkdir test ~$ cd test test$ mkdir -p src/a trg/a test$ echo "/a/b/c" > list test$ /usr/bin/rsync -slt --ignore-errors --force

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #6 from Marc Krämer --- ups, didn't get a notice from your reply. Thanks for your explanation. This was not obvious to me. It should be documented, the behaviour has changed. You can close this one, thanks. -- You are receiving

[Bug 13734] New: spelling mistakes in rsync.yo

https://bugzilla.samba.org/show_bug.cgi?id=13734 Bug ID: 13734 Summary: spelling mistakes in rsync.yo Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: trivial Priority:

[Bug 13735] New: Synchronize files when the sending side has newer change times while modification times and sizes are identical on both sides

https://bugzilla.samba.org/show_bug.cgi?id=13735 Bug ID: 13735 Summary: Synchronize files when the sending side has newer change times while modification times and sizes are identical on both sides Product: rsync

[Bug 13749] New: Add more extensions to DEFAULT_DONT_COMPRESS

https://bugzilla.samba.org/show_bug.cgi?id=13749 Bug ID: 13749 Summary: Add more extensions to DEFAULT_DONT_COMPRESS Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: enhancement

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #11 from Paul Slootman --- Created attachment 14775 --> https://bugzilla.samba.org/attachment.cgi?id=14775=edit proposed patch This patch is based on the patch posted earlier, but checks the options --delete-missing-args and

[Bug 13735] Synchronize files when the sending side has newer change times while modification times and sizes are identical on both sides

https://bugzilla.samba.org/show_bug.cgi?id=13735 Wayne Davison changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 13692] Coverity scan for rsync-3.1.3

https://bugzilla.samba.org/show_bug.cgi?id=13692 Wayne Davison changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 13735] Synchronize files when the sending side has newer change times while modification times and sizes are identical on both sides

https://bugzilla.samba.org/show_bug.cgi?id=13735 --- Comment #3 from Sébastien Béhuret --- Thank you for suggesting the patches repo. An improved checksum/maybe-checksum algorithm would be great but there appears to be a lot of work to achieve this. Checksums are very handy for special cases

[Bug 13707] New: zlib/inflate.c:1528

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

[Bug 13582] rsync filters containing multiple adjacent slashes aren't reduced to just one slash before matching

https://bugzilla.samba.org/show_bug.cgi?id=13582 Wayne Davison changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW

[Bug 13645] Improve efficiency when resuming transfer of large files

https://bugzilla.samba.org/show_bug.cgi?id=13645 Wayne Davison changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 13615] Output of --list-only not as I expected re: symlinks

https://bugzilla.samba.org/show_bug.cgi?id=13615 --- Comment #3 from Kevin Korb --- I believe I talked to you in IRC about which is why I didn't respond when this was first posted but I think I can help explain this better... The --list-only option is to turn rsync into a network capable ls.

[Bug 13522] Patch fileflags.diff and crtimes.diff

https://bugzilla.samba.org/show_bug.cgi?id=13522 Wayne Davison changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 13615] Output of --list-only not as I expected re: symlinks

https://bugzilla.samba.org/show_bug.cgi?id=13615 Wayne Davison changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 13615] Output of --list-only not as I expected re: symlinks

https://bugzilla.samba.org/show_bug.cgi?id=13615 --- Comment #2 from Michael Hipp --- I'm sorry, I don't understand. The first line in the docs says: "This option will cause the source files to be listed instead of transferred." It doesn't say anything about "remote". It would seem to be a

[Bug 13467] an xattr filter rule is treated as a file filter rule on the remote side

https://bugzilla.samba.org/show_bug.cgi?id=13467 Wayne Davison changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 13492] report modified dir when using iconv

https://bugzilla.samba.org/show_bug.cgi?id=13492 Wayne Davison changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 13615] Output of --list-only not as I expected re: symlinks

https://bugzilla.samba.org/show_bug.cgi?id=13615 --- Comment #4 from Michael Hipp --- (In reply to Kevin Korb from comment #3) Thanks for the explanation. I would encourage someone to consider updating the documentation to be more like what you wrote - as what I get from reading the man page is

[Bug 13645] Improve efficiency when resuming transfer of large files

https://bugzilla.samba.org/show_bug.cgi?id=13645 --- Comment #4 from Rob Janssen --- Ok you apparently did not understand what I proposed. However it is not that important as in our use case we can use --append. -- You are receiving this mail because: You are the QA Contact for the bug. --

[Bug 13522] Patch fileflags.diff and crtimes.diff

https://bugzilla.samba.org/show_bug.cgi?id=13522 --- Comment #2 from jief --- Hi, I can compile it and use it (I use rsync almost every day). I'm not saying it'll comprehensive tests will all use cases possible, but it'll be some tests. But where can I get the source. Can only see the tar ball

[Bug 13692] New: Coverity scan for rsync-3.1.3

https://bugzilla.samba.org/show_bug.cgi?id=13692 Bug ID: 13692 Summary: Coverity scan for rsync-3.1.3 Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority:

[Bug 13734] spelling mistakes in rsync.yo

https://bugzilla.samba.org/show_bug.cgi?id=13734 Wayne Davison changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug 13707] zlib/inflate.c:1528

https://bugzilla.samba.org/show_bug.cgi?id=13707 Wayne Davison changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 13522] Patch fileflags.diff and crtimes.diff

https://bugzilla.samba.org/show_bug.cgi?id=13522 --- Comment #3 from Wayne Davison --- The download page mentions all of the ways to grab the source, including git: https://rsync.samba.org/download.html The git source is safe, as it only contains bug fixes since the last release. -- You are

[Bug 13609] rsync can be crazy slow on os x 10.13.6 when copying via usb drives

https://bugzilla.samba.org/show_bug.cgi?id=13609 --- Comment #2 from mvola...@aecom.yu.edu --- I should also mention the file being copied so slowly is a Virtualbox virtual disk file. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most

[Bug 13615] New: Output of --list-only not as I expected re: symlinks

https://bugzilla.samba.org/show_bug.cgi?id=13615 Bug ID: 13615 Summary: Output of --list-only not as I expected re: symlinks Product: rsync Version: 3.1.3 Hardware: x64 OS: Linux Status: NEW Severity:

<    1   2   3   4   5   6   7   >