[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 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 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 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 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 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 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 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 #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 #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 #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 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 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] 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 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:

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

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

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

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

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

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

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

[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

[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 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=edit Patch using FLAG_PERHAPS_DIR Here is a working patch using the method detailed in comment #2. -- You are receiving this

[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

[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

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

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

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

<    1   2   3   4   5   6   7   >