[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 --ignore-errors /data/data r...@l-rel-dnl.

[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 write(). safe_write() does

[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: 810 if ((n = write

[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 --delete-after --fo

[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 --whole-files switch if that pro

[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 on MacBook, MacB

[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 parameter, that causes missin

[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) that can be sent to rsync

[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 Status|NEW

[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 unsubscribe or change options: ht

[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: N

[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 owner, and convenient

[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 ... When this parame

[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 daemon's directory: $

[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 original links back is to pull the resto

[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 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 written (bug's still there)

[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: %y" {a,b}/link a/link: 20

[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: All

[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 protocol data stream (code

[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 #7 from Chris Tipper --- Sorry for hijacking your bug but I had an issue and did not want to create a separate report. And you may have verified your bug to your own satisfaction but not provided any diagnostic. So I don't see how it ca

[Bug 13423] New: Checksum option does not work as expected when append-verify is used

https://bugzilla.samba.org/show_bug.cgi?id=13423 Bug ID: 13423 Summary: Checksum option does not work as expected when append-verify is used Product: rsync Version: 3.1.3 Hardware: All OS: All St

[Bug 13423] Checksum option does not work as expected when append-verify is used

https://bugzilla.samba.org/show_bug.cgi?id=13423 --- Comment #1 from Kevin Korb --- If the file has not grown then there is nothing for --append[-verify] to do. Also, without --itemize-changes you have no reporting from --checksum. You probably shouldn't have either option. -- You are receivi

[Bug 13423] Checksum option does not work as expected when append-verify is used

https://bugzilla.samba.org/show_bug.cgi?id=13423 --- Comment #2 from dariu...@me.com --- Yes it is clear that --append-verify will not update the same size files. But --checksum should check hashes of all files and trigger update if different. What is happening here looks like append-verify over

[Bug 13423] Checksum option does not work as expected when append-verify is used

https://bugzilla.samba.org/show_bug.cgi?id=13423 --- Comment #3 from Kevin Korb --- >From man rsync --append: > If a file needs to be transferred and its size on the receiver is the same or > longer than the size on the sender, the file is skipped. --append-verify does the verify AFTER an appen

[Bug 13423] Checksum option does not work as expected when append-verify is used

https://bugzilla.samba.org/show_bug.cgi?id=13423 --- Comment #4 from dariu...@me.com --- Thank you for clarification. -- 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 unsubscribe or chang

[Bug 13433] New: out_of_memory in receive_sums on large files

https://bugzilla.samba.org/show_bug.cgi?id=13433 Bug ID: 13433 Summary: out_of_memory in receive_sums on large files Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal

[Bug 13433] out_of_memory in receive_sums on large files

https://bugzilla.samba.org/show_bug.cgi?id=13433 --- Comment #1 from Dave Gordon --- Maybe try --block-size=10485760 --protocol=29 as mentioned here: https://bugzilla.samba.org/show_bug.cgi?id=10518#c8 -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use r

[Bug 13433] out_of_memory in receive_sums on large files

https://bugzilla.samba.org/show_bug.cgi?id=13433 --- Comment #2 from Kevin Day --- (In reply to Dave Gordon from comment #1) It looks like that's no longer allowed? rsync: --block-size=10485760 is too large (max: 131072) rsync error: syntax or usage error (code 1) at main.c(1591) [client=3.1.3]

[Bug 13433] out_of_memory in receive_sums on large files

https://bugzilla.samba.org/show_bug.cgi?id=13433 --- Comment #3 from Kevin Day --- Just adding --protocol=29 falls back to the older chunk generator code and automatically selects 2MB chunks which is enough to at least make this work without a malloc error. -- You are receiving this mail becaus

[Bug 13445] New: Fuzzy searching in link-dest tries to open regular file as directory

https://bugzilla.samba.org/show_bug.cgi?id=13445 Bug ID: 13445 Summary: Fuzzy searching in link-dest tries to open regular file as directory Product: rsync Version: 3.1.3 Hardware: All OS: All St

[Bug 13445] Fuzzy searching in link-dest tries to open regular file as directory

https://bugzilla.samba.org/show_bug.cgi?id=13445 --- Comment #1 from Einhard Leichtfuß --- Maybe more or less related: Bug 11866 [0], Bug 12489 [1] [0] https://bugzilla.samba.org/show_bug.cgi?id=11866 [1] https://bugzilla.samba.org/show_bug.cgi?id=12489 -- You are receiving this mail because:

[Bug 13445] Fuzzy searching in link-dest tries to open regular file as directory

https://bugzilla.samba.org/show_bug.cgi?id=13445 --- Comment #3 from Ben RUBSON --- We could also stat() fnamecmpbuf in recv_generator(), but I think it's rather interesting to save such calls. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all

[Bug 13445] Fuzzy searching in link-dest tries to open regular file as directory

https://bugzilla.samba.org/show_bug.cgi?id=13445 --- Comment #2 from Ben RUBSON --- Nice catch, I was able to easily reproduce this issue just creating a directory with the name of a just-deleted file. The path you mention Einhard seems to be the only one where no check is done to be sure a dire

[Bug 13433] out_of_memory in receive_sums on large files

https://bugzilla.samba.org/show_bug.cgi?id=13433 --- Comment #4 from Ben RUBSON --- util2.c:#define MALLOC_MAX 0x4000 Which is 1 GB. 1 GB / 40 bytes x 131072 bytes = 3276 GB, which is then the maximum file size in protocol_version >= 30. Did you try to increase MALLOC_MAX on sending side ?

[Bug 13445] Fuzzy searching in link-dest tries to open regular file as directory

https://bugzilla.samba.org/show_bug.cgi?id=13445 --- Comment #4 from Einhard Leichtfuß --- Did I understand correctly that you were able to reproduce this in a notably different way? I had not sufficiently examined the code to see that in all the other cases the existance of a directory is made

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #2 from Axel Kittenberger --- shouldn't "--ignore-errors" already be that parameter? It uses --force also. --ignore-errors --force --i-really-mean-it? :) -- You are receiving this mail because: You are the QA Contact for the bug. --

[Bug 13445] Fuzzy searching in link-dest tries to open regular file as directory

https://bugzilla.samba.org/show_bug.cgi?id=13445 --- Comment #5 from Ben RUBSON --- I reproduced the issue the same way, I meant just creating a directory in my backed-up tree with the name of a just-deleted file, this file remaining in the link-dest folder. I'm not sure the opposite (an existin

[Bug 13463] New: Please consider using the IP_FREEBIND socket option

https://bugzilla.samba.org/show_bug.cgi?id=13463 Bug ID: 13463 Summary: Please consider using the IP_FREEBIND socket option Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: enhance

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #3 from Marc Krämer --- that is my understanding too! And this was true before the last release. Basic tools like rsync should not break their behaviour! -- You are receiving this mail because: You are the QA Contact for the bug. --

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #4 from Marc Krämer --- My bugreport at mageia: https://bugs.mageia.org/show_bug.cgi?id=21395 -- 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

[Bug 13463] Please consider using the IP_FREEBIND socket option

https://bugzilla.samba.org/show_bug.cgi?id=13463 --- Comment #1 from Carson Gaspar --- If this is done, please make it optional. I want my daemon to break when given an invalid config, e.g. a typo'd IP address. The fact that systemd folks are crazy and people don't want to have proper startup dep

[Bug 13445] Fuzzy searching in link-dest tries to open regular file as directory

https://bugzilla.samba.org/show_bug.cgi?id=13445 --- Comment #6 from Ben RUBSON --- Created attachment 14231 --> https://bugzilla.samba.org/attachment.cgi?id=14231&action=edit Patch using FLAG_PERHAPS_DIR Here is a working patch using the method detailed in comment #2. -- You are receiving t

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

https://bugzilla.samba.org/show_bug.cgi?id=13467 Bug ID: 13467 Summary: an xattr filter rule is treated as a file filter rule on the remote side Product: rsync Version: 3.1.3 Hardware: All OS: All

[Bug 13463] Please consider using the IP_FREEBIND socket option

https://bugzilla.samba.org/show_bug.cgi?id=13463 --- Comment #2 from Kevin Korb --- I agree with Carson. If rsync is told to do the impossible it should fail with an appropriate error and exit code. Unfortunately I would also have to argue that the current behaviour is wrong because it does not

[Bug 11978] mkstemp failed: File name too long (36) when filename is under the limit

https://bugzilla.samba.org/show_bug.cgi?id=11978 Mauro Molinari changed: What|Removed |Added CC||mauro...@tiscali.it --- Comment #3 from M

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

[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 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 32-bi

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

https://bugzilla.samba.org/show_bug.cgi?id=13496 Peter Koch changed: What|Removed |Added Resolution|--- |INVALID Status|NEW

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

https://bugzilla.samba.org/show_bug.cgi?id=13522 Bug ID: 13522 Summary: Patch fileflags.diff and crtimes.diff Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Prio

[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 13569] New: --link-dest may follow symlinks and failure to hard link a non-regular file is fatal

https://bugzilla.samba.org/show_bug.cgi?id=13569 Bug ID: 13569 Summary: --link-dest may follow symlinks and failure to hard link a non-regular file is fatal Product: rsync Version: 3.1.3 Hardware: All OS: Al

[Bug 12569] Missing directory errors not ignored

https://bugzilla.samba.org/show_bug.cgi?id=12569 --- Comment #5 from Dave Gordon --- I think you need to add "--no-implied-dirs" to get the behaviour you want. The issue is that the contents list contains /a/b/c, so problems with that specific file are suppressed by "--ignore-missing-args", but

[Bug 11588] better handling for --preallocate with --sparse

https://bugzilla.samba.org/show_bug.cgi?id=11588 --- Comment #26 from Marcus Linsner --- There is a fix for this feature, here: https://bugzilla.samba.org/show_bug.cgi?id=13320 It worksforme. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all

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

https://bugzilla.samba.org/show_bug.cgi?id=13320 --- Comment #4 from Marcus Linsner --- Thanks for this fix Dave, worksforme! -- 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 unsubscrib

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

https://bugzilla.samba.org/show_bug.cgi?id=13582 Bug ID: 13582 Summary: rsync filters containing multiple adjacent slashes aren't reduced to just one slash before matching Product: rsync Version: 3.1.3 Hardware: x64

[Bug 13586] New: Missing HTTP header for rsync-3.1.3-NEWS

https://bugzilla.samba.org/show_bug.cgi?id=13586 Bug ID: 13586 Summary: Missing HTTP header for rsync-3.1.3-NEWS Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: trivial

[Bug 13587] New: Add a --dry-run way to show destination for each item

https://bugzilla.samba.org/show_bug.cgi?id=13587 Bug ID: 13587 Summary: Add a --dry-run way to show destination for each item Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: norma

[Bug 13587] Add a --dry-run way to show destination for each item

https://bugzilla.samba.org/show_bug.cgi?id=13587 --- Comment #1 from Dan Jacobson --- Thank you for https://lists.samba.org/archive/rsync/2018-August/031701.html I was hoping for something simple like $ cp -v m n 'm' -> 'n' i.e., like a theoretical cp --dry-run -v with no need for complicated %

[Bug 5792] rsync fails to log files "sent" with options: --itemize-changes -n --log-file

https://bugzilla.samba.org/show_bug.cgi?id=5792 Stéphane Gourichon changed: What|Removed |Added CC||stephane_sambabugz@gouricho

[Bug 13608] New: Assertion failed: (f_out >= 0), function send_xattr_request

https://bugzilla.samba.org/show_bug.cgi?id=13608 Bug ID: 13608 Summary: Assertion failed: (f_out >= 0), function send_xattr_request Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW

[Bug 13609] New: 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 Bug ID: 13609 Summary: rsync can be crazy slow on os x 10.13.6 when copying via usb drives Product: rsync Version: 3.1.3 Hardware: All OS: All Sta

[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 #1 from mvola...@aecom.yu.edu --- The sparse option is triggering this slowness. Without it, rsync runs super fast. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies

[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: norm

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

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

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

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

[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 --ignore-missi

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

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

[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 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: L

[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: N

[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: https://github

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

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

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

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

[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: P5

[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 5109] poor performance on large drives with big bandwidth

https://bugzilla.samba.org/show_bug.cgi?id=5109 Björn Jacke changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[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: P

[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 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 #1 from Kevin Korb --- Yes, a user can back-date the mtime on a file. This is what rsync does when it copies a file then copies the timestamp. Your suggestion of a better --checksum option is an interesting idea but so far we don't ev

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

<    1   2   3   4   5   6   7   >