[Bug 13061] File lost on case-insensitive file system

https://bugzilla.samba.org/show_bug.cgi?id=13061 --- Comment #1 from Kevin Korb --- Are you saying that it deleted a file AFTER saying "IO error encountered -- skipping file deletion"? Maybe you need some --itemize-changes to make sure. Unfortunately, this is a limitation

[Bug 13061] New: File lost on case-insensitive file system

https://bugzilla.samba.org/show_bug.cgi?id=13061 Bug ID: 13061 Summary: File lost on case-insensitive file system Product: rsync Version: 3.1.3 Hardware: All OS: Windows 7 Status: NEW Severity: major

[Bug 13044] On macOS 10.12.6 with the new Xcode 9, `make check` is full of failures

https://bugzilla.samba.org/show_bug.cgi?id=13044 --- Comment #6 from chd...@gmail.com --- Homebrew's builds for different macOS versions will use as few versions of Xcode as possible. Sometimes one version of Xcode is used on two different macOS VMs with differing macOS versions. Anyway, those

[Bug 13044] On macOS 10.12.6 with the new Xcode 9, `make check` is full of failures

https://bugzilla.samba.org/show_bug.cgi?id=13044 --- Comment #5 from Andrey Gursky --- > Xcode 9 (which only comes with a 10.13 SDK) I guess you obviously will not be able to compile programs for other macOS versions with such Xcode 9. Unless you install the appropriate

[Bug 13044] On macOS 10.12.6 with the new Xcode 9, `make check` is full of failures

https://bugzilla.samba.org/show_bug.cgi?id=13044 --- Comment #4 from chd...@gmail.com --- Communicating with Homebrew today, it's still not clear whether this because of anything they're doing, or whether rsync will have to do something to accommodate the combination of Xcode 9 (which only comes

[Bug 13044] On macOS 10.12.6 with the new Xcode 9, `make check` is full of failures

https://bugzilla.samba.org/show_bug.cgi?id=13044 --- Comment #3 from Ben RUBSON --- Nearly off topic, but what is the embedded rsync version in Mac OS 10.13 ? 10.11 still uses 2.6.9 :| ... Thx ! -- You are receiving this mail because: You are the QA Contact for the bug.

[Bug 13044] On macOS 10.12.6 with the new Xcode 9, `make check` is full of failures

https://bugzilla.samba.org/show_bug.cgi?id=13044 --- Comment #2 from Andrey Gursky --- utimensat() specified in POSIX.1-2008 (about 9! years ago) has been (at last!) added in macOS 10.13. So if you've compiled binary using latest Xcode i.e. for macOS 10.13, then it

[Bug 13044] On macOS 10.12.6 with the new Xcode 9, `make check` is full of failures

https://bugzilla.samba.org/show_bug.cgi?id=13044 --- Comment #1 from chd...@gmail.com --- Hmmm, I can only reproduce this when using Homebrew. I've reported this to them, so we'll see whether it's their "fault" or whether rsync needs to adjust for Xcode 9. -- You are receiving this mail

[Bug 13044] New: On macOS 10.12.6 with the new Xcode 9, `make check` is full of failures

https://bugzilla.samba.org/show_bug.cgi?id=13044 Bug ID: 13044 Summary: On macOS 10.12.6 with the new Xcode 9, `make check` is full of failures Product: rsync Version: 3.1.2 Hardware: x86 OS: Mac OS X

[Bug 12817] [PATCH] Allow daemon itself to chroot

https://bugzilla.samba.org/show_bug.cgi?id=12817 --- Comment #5 from Ben RUBSON --- Many thanks Wayne for having reworked & merged it ! -- 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 12817] [PATCH] Allow daemon itself to chroot

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

[Bug 10715] IPv6 configure test fails on musl c-library

https://bugzilla.samba.org/show_bug.cgi?id=10715 Pierre-Olivier Mercier changed: What|Removed |Added CC|

[Bug 12955] [patch] Fix rsync -A on AIX

https://bugzilla.samba.org/show_bug.cgi?id=12955 Cun Gong changed: What|Removed |Added Attachment #13458|0 |1 is obsolete|

[Bug 12964] New: Maybe we can add the '--bind-cpu' option

https://bugzilla.samba.org/show_bug.cgi?id=12964 Bug ID: 12964 Summary: Maybe we can add the '--bind-cpu' option Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: trivial

[Bug 12955] New: [patch] Fix rsync -A on AIX

https://bugzilla.samba.org/show_bug.cgi?id=12955 Bug ID: 12955 Summary: [patch] Fix rsync -A on AIX Product: rsync Version: 3.1.2 Hardware: PPC OS: AIX Status: NEW Severity: normal Priority: P5

[Bug 12942] Traffic shaping: Make --bwlimit dynamic

https://bugzilla.samba.org/show_bug.cgi?id=12942 --- Comment #2 from kapo...@gmail.com --- Hi Roland, thanks for your help. I looked at your solution: export RSYNC_RSH="sh -c 'pv -qL10k | ssh \"\$@\" | (pv -qL11k; kill \$\$)' ssh" Of course using $$ was

[Bug 12942] Traffic shaping: Make --bwlimit dynamic

https://bugzilla.samba.org/show_bug.cgi?id=12942 --- Comment #1 from roland --- see https://bugzilla.samba.org/show_bug.cgi?id=7120 -- 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 12942] New: Traffic shaping: Make --bwlimit dynamic

https://bugzilla.samba.org/show_bug.cgi?id=12942 Bug ID: 12942 Summary: Traffic shaping: Make --bwlimit dynamic Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal

[Bug 12940] New: rsync: -C/--cvs-exclude does not ignore SCM ignore files (patch)

https://bugzilla.samba.org/show_bug.cgi?id=12940 Bug ID: 12940 Summary: rsync: -C/--cvs-exclude does not ignore SCM ignore files (patch) Product: rsync Version: 3.1.3 Hardware: All OS: All

[Bug 12769] error allocating core memory buffers (code 22) depending on source file system

https://bugzilla.samba.org/show_bug.cgi?id=12769 --- Comment #3 from Roland Haberkorn --- Ok, I digged somewhat deeper. I've found a second difference between my two sources. The one is the original data, the other one is a diffential rsync backup with hard links. I then built a

[Bug 12920] New: Invalid path from sender

https://bugzilla.samba.org/show_bug.cgi?id=12920 Bug ID: 12920 Summary: Invalid path from sender Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal Priority: P5

[Bug 12915] --modify-window should default to 1 for fat filesystems

https://bugzilla.samba.org/show_bug.cgi?id=12915 --- Comment #8 from Kevin Korb --- The 3602 problem happens when the clocks change not the entire time the clocks are different. If you do a daily rsync then rsync will see 1 hour off timestamps the day after both clock

[Bug 12915] --modify-window should default to 1 for fat filesystems

https://bugzilla.samba.org/show_bug.cgi?id=12915 --- Comment #7 from Ian Kelling --- > But here in the US for half of the year you need --modify-window=3602 instead. I think people use vfat because there are a lot of devices out there like android which require it, and they only

[Bug 12915] --modify-window should default to 1 for fat filesystems

https://bugzilla.samba.org/show_bug.cgi?id=12915 --- Comment #6 from Ben RUBSON --- Just to clarify, is FAT32 also impacted and requires --modify-window option, or only the old one FAT is ? Thx ! -- You are receiving this mail because: You are the QA Contact for the bug.

[Bug 12915] --modify-window should default to 1 for fat filesystems

https://bugzilla.samba.org/show_bug.cgi?id=12915 --- Comment #5 from Kevin Korb --- Actually, I looked it up. It wasn't actually my request I had already dealt with the problem. This is the ticket from the person I was helping:

[Bug 12915] --modify-window should default to 1 for fat filesystems

https://bugzilla.samba.org/show_bug.cgi?id=12915 --- Comment #4 from Kevin Korb --- The manual says that with FAT you need --modify-window=2 not 1. But here in the US for half of the year you need --modify-window=3602 instead. The same goes for many other locations. The

[Bug 12915] --modify-window should default to 1 for fat filesystems

https://bugzilla.samba.org/show_bug.cgi?id=12915 --- Comment #3 from Brian K. White --- (In reply to Ian Kelling from comment #2) The manuals says useful not helpful. The manual does not say it's good or bad or recommended or any other value judgement. It only describes it's

[Bug 12916] when rsync fails to chown, it gives up and does not set timestamp

https://bugzilla.samba.org/show_bug.cgi?id=12916 --- Comment #2 from Ian Kelling --- Great tip. If we can solve it that would be good too. -- 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 12915] --modify-window should default to 1 for fat filesystems

https://bugzilla.samba.org/show_bug.cgi?id=12915 --- Comment #2 from Ian Kelling --- > This would not actually be very helpful. Why? You haven't said. The manual says it's helpful and it's helpful for me. -- You are receiving this mail because: You are the QA Contact for the

[Bug 12916] when rsync fails to chown, it gives up and does not set timestamp

https://bugzilla.samba.org/show_bug.cgi?id=12916 --- Comment #1 from Kevin Korb --- If you mount your FAT filesystems with the quiet option the FAT driver will just ignore the operations it can't do instead of throwing fatal errors at you. This will resolve problems in

[Bug 12915] --modify-window should default to 1 for fat filesystems

https://bugzilla.samba.org/show_bug.cgi?id=12915 --- Comment #1 from Kevin Korb --- This would not actually be very helpful. Going between a *nix style timestamp and a FAT one has other issues. Especially if your TZ changes or you are in a TZ where the clock changes twice

[Bug 12916] New: when rsync fails to chown, it gives up and does not set timestamp

https://bugzilla.samba.org/show_bug.cgi?id=12916 Bug ID: 12916 Summary: when rsync fails to chown, it gives up and does not set timestamp Product: rsync Version: 3.1.3 Hardware: All OS: All

[Bug 12915] New: --modify-window should default to 1 for fat filesystems

https://bugzilla.samba.org/show_bug.cgi?id=12915 Bug ID: 12915 Summary: --modify-window should default to 1 for fat filesystems Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW

[Bug 11866] rsync fails (failed to re-stat) when using double fuzzy + link-dest on renamed files

https://bugzilla.samba.org/show_bug.cgi?id=11866 --- Comment #2 from Ben RUBSON --- Created attachment 13342 --> https://bugzilla.samba.org/attachment.cgi?id=13342=edit rsync_double_fuzzy_11866 Bug found, patch attached. Wayne could you please review and commit please ?

[Bug 11866] rsync fails (failed to re-stat) when using double fuzzy + link-dest on renamed files

https://bugzilla.samba.org/show_bug.cgi?id=11866 --- Comment #1 from Ben RUBSON --- I can easily reproduce this dangerous bug. Both sides running rsync 3.1.2. # cd /tmp/ && mkdir -p test && cd test && rm -f * # ssh $usr@$srv "rm -rf /tmp/dst*" # for i in `seq 0 9` do

[Bug 12173] memory leak around poptGetOptArg()

https://bugzilla.samba.org/show_bug.cgi?id=12173 --- Comment #3 from T Yamada --- > definitely lost: 4 bytes in 1 blocks For entire program. But maybe this priority is low. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use

[Bug 12173] memory leak around poptGetOptArg()

https://bugzilla.samba.org/show_bug.cgi?id=12173 --- Comment #2 from Paul Slootman --- I think there are more urgent problems than a memory leak of less than 1kB, which I expect isn't really a leak but memory which isn't freed at the end of execution but may be used up to that

[Bug 12173] memory leak around poptGetOptArg()

https://bugzilla.samba.org/show_bug.cgi?id=12173 T Yamada changed: What|Removed |Added Version|3.0.6 |3.1.1 --- Comment #1

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

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #8 from Brian K. White --- You tell me, what ABOUT a power failure between 2 zfs, or any other fs operations? This does not improve or solve any problem that the fs and all the other layers aren't already handling.

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

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #7 from Ben RUBSON --- And what about a power failure between 2 ZFS transaction groups ? Note that my patch simply adds a sync() just after recv_files(), so one sync() per connection, not per write operation.

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

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #6 from Brian K. White --- Think of it this way, write() already makes a certain promise that it will not return until it's done it's job, and it will not assert success when it can't. Essentially the man page for any

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

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #5 from Brian K. White --- Any program could make this same "just to be safe" argument practically every time they ever close-on-write for any reason. If they wrote anything, it was always for some reason, and they

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

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #4 from Ben RUBSON --- Yes Paul I thought about it but sync command may not be available if the server (receiver) is chrooted (for example using patch proposed in #12817). -- You are receiving this mail because:

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

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #3 from Paul Slootman --- How about just using a post-xfer command on the server side that does 'sync'? -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most

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

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #2 from Ben RUBSON --- Thank you for your feedback Brian. I don't have any problem. I just want to be sure that when client (sender) has finished its transfer, its data is on server's (receiver) disks, before it

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

https://bugzilla.samba.org/show_bug.cgi?id=12819 --- Comment #1 from Brian K. White --- This seems wrong to me. If the OS is failing to manage write buffers and file access between processes, you would have a lot bigger problems in every process all through the system, and this

[Bug 12838] [PATCH] Log sent/received bytes even in case of error

https://bugzilla.samba.org/show_bug.cgi?id=12838 --- Comment #1 from Ben RUBSON --- Mmmmh unfortunately numbers are not correct. # Sender side (which interrupts the transfer receiving SIGUSR2) : Total file size: 16­.85G bytes Total transferred file size: 183­.38M bytes

[Bug 12838] New: [PATCH] Log sent/received bytes even in case of error

https://bugzilla.samba.org/show_bug.cgi?id=12838 Bug ID: 12838 Summary: [PATCH] Log sent/received bytes even in case of error Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity:

[Bug 12835] New: Allow --link-dest to link to an optionally unexisting directory

https://bugzilla.samba.org/show_bug.cgi?id=12835 Bug ID: 12835 Summary: Allow --link-dest to link to an optionally unexisting directory Product: rsync Version: 3.1.3 Hardware: All OS: All

[Bug 12806] Deleting in a row of hardlinked snapshots resets file permissions.

https://bugzilla.samba.org/show_bug.cgi?id=12806 --- Comment #5 from Heinz-Willi Wyes --- Lars Ellenberg provided a workaround for the behaviour. Using rsync -d --delete --super `mktemp -d`/ snapshots/2017-05-26-15-00-53/ plays the trick. Not sure whether the --super

[Bug 12806] Deleting in a row of hardlinked snapshots resets file permissions.

https://bugzilla.samba.org/show_bug.cgi?id=12806 --- Comment #4 from Heinz-Willi Wyes --- I got a personal message from Lars Ellenberg that went also to samba-b...@samba.org and rsync...@samba.org. He wrote: -- Calling chmod only on (optimization:

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

https://bugzilla.samba.org/show_bug.cgi?id=12820 Bug ID: 12820 Summary: rsync always try change owner and group of symlink in --fake-super mode Product: rsync Version: 3.0.9 Hardware: All OS: All

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

https://bugzilla.samba.org/show_bug.cgi?id=12819 Bug ID: 12819 Summary: [PATCH] sync() on receiving side for data consistency Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity:

[Bug 12817] [PATCH] Allow daemon itself to chroot

https://bugzilla.samba.org/show_bug.cgi?id=12817 Ben RUBSON changed: What|Removed |Added Attachment #13250|0 |1 is obsolete|

[Bug 12817] [PATCH] Allow daemon itself to chroot

https://bugzilla.samba.org/show_bug.cgi?id=12817 Ben RUBSON changed: What|Removed |Added Attachment #13249|0 |1 is obsolete|

[Bug 12817] [PATCH] Allow daemon itself to chroot

https://bugzilla.samba.org/show_bug.cgi?id=12817 Ben RUBSON changed: What|Removed |Added Attachment #13248|0 |1 is obsolete|

[Bug 12817] New: [PATCH] Allow daemon itself to chroot

https://bugzilla.samba.org/show_bug.cgi?id=12817 Bug ID: 12817 Summary: [PATCH] Allow daemon itself to chroot Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal

[Bug 12806] Deleting in a row of hardlinked snapshots resets file permissions.

https://bugzilla.samba.org/show_bug.cgi?id=12806 --- Comment #3 from Heinz-Willi Wyes --- (In reply to Kevin Korb from comment #2) I'd like to, but I can't. I set up a local scenario in order to make the problem most easily reproducible. But the real use case involves

[Bug 12806] Deleting in a row of hardlinked snapshots resets file permissions.

https://bugzilla.samba.org/show_bug.cgi?id=12806 --- Comment #2 from Kevin Korb --- Just use rm -rf to delete a backup. -- 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

[Bug 12806] Deleting in a row of hardlinked snapshots resets file permissions.

https://bugzilla.samba.org/show_bug.cgi?id=12806 --- Comment #1 from Heinz-Willi Wyes --- Addendum. Thought that the --inplace option could play the trick. I just employed the following: rsync -r --delete --inplace `mktemp -d`/ snapshots/2017-05-28-08-10-11/ But this

[Bug 12806] New: Deleting in a row of hardlinked snapshots resets file permissions.

https://bugzilla.samba.org/show_bug.cgi?id=12806 Bug ID: 12806 Summary: Deleting in a row of hardlinked snapshots resets file permissions. Product: rsync Version: 3.1.0 Hardware: All OS: All

[Bug 10738] report --stats output when termination signal arrives

https://bugzilla.samba.org/show_bug.cgi?id=10738 --- Comment #6 from Ben RUBSON --- Mmmh however some of the statistics seem to be wrongly calculated. ### Example with tsync 3.1.2 : Number of files: 8,732 (reg: 7,568, dir: 1,163, link: 1) Number of created files: 1,232

[Bug 10738] report --stats output when termination signal arrives

https://bugzilla.samba.org/show_bug.cgi?id=10738 --- Comment #5 from Ben RUBSON --- So I just went through the code and found that this feature request is already implemented. We just have to use SIGUSR2 and rsync will stop, displaying stats. kill -USR2 Perfect ! -- You

[Bug 12781] rsync library

https://bugzilla.samba.org/show_bug.cgi?id=12781 --- Comment #1 from Axel Kittenberger --- I asked exactly this 10 years ago to the mailing list. The answer was no. This is not a simple to do. You could do it, I decided that kind of project would move me too far away from

[Bug 10738] report --stats output when termination signal arrives

https://bugzilla.samba.org/show_bug.cgi?id=10738 Ben RUBSON changed: What|Removed |Added CC||ben.rub...@gmail.com

[Bug 12769] error allocating core memory buffers (code 22) depending on source file system

https://bugzilla.samba.org/show_bug.cgi?id=12769 --- Comment #2 from Roland Haberkorn --- I did some further investigation... First thing to add: The ext4 file systems are hard-linked differential rsync backups of the real data on XFS. I changed the testcase by deleting the

[Bug 12781] New: rsync library

https://bugzilla.samba.org/show_bug.cgi?id=12781 Bug ID: 12781 Summary: rsync library Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5

[Bug 12769] error allocating core memory buffers (code 22) depending on source file system

https://bugzilla.samba.org/show_bug.cgi?id=12769 --- Comment #1 from Roland Haberkorn --- If you want me to run further testings with other file systems I am totally willing to produce fake data and run tests. I just haven't done yet because of my lack of knowledge about the

[Bug 12769] New: error allocating core memory buffers (code 22) depending on source file system

https://bugzilla.samba.org/show_bug.cgi?id=12769 Bug ID: 12769 Summary: error allocating core memory buffers (code 22) depending on source file system Product: rsync Version: 3.1.0 Hardware: All OS: Linux

[Bug 12755] [patch] Improve execution speed on Windows; with Win32 API calls

https://bugzilla.samba.org/show_bug.cgi?id=12755 --- Comment #2 from Joseph Benden --- Please disregard the patch attachment as the actual definitive solution and rather visit my GitHub repository for the current working source and binaries. If this solution is accepted for

[Bug 12755] [patch] Improve execution speed on Windows; with Win32 API calls

https://bugzilla.samba.org/show_bug.cgi?id=12755 Wayne Davison changed: What|Removed |Added Attachment #13169|application/mbox|text/plain

[Bug 12583] [PATCH] Add new daemon option "syslog tag"

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

[Bug 12583] [PATCH] Add new daemon option "syslog tag"

https://bugzilla.samba.org/show_bug.cgi?id=12583 --- Comment #2 from Ben RUBSON --- Wayne thank you very much !! Really perfect :) Many thx ! -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies to avoid

[Bug 12755] [patch] Improve execution speed on Windows; with Win32 API calls

https://bugzilla.samba.org/show_bug.cgi?id=12755 --- Comment #1 from Joseph Benden --- If anyone wishes to test the compiled binary, it's available for download here: https://github.com/jbenden/rsync/releases -- You are receiving this mail because: You are the QA Contact for

[Bug 12755] New: [patch] Improve execution speed on Windows; with Win32 API calls

https://bugzilla.samba.org/show_bug.cgi?id=12755 Bug ID: 12755 Summary: [patch] Improve execution speed on Windows; with Win32 API calls Product: rsync Version: 3.1.3 Hardware: All OS: Windows 10

[Bug 12519] [PATCH] Failed to open lock file, add reason

https://bugzilla.samba.org/show_bug.cgi?id=12519 Ben RUBSON changed: What|Removed |Added Resolution|--- |LATER

[Bug 12742] New: a proposal: fix bogus nanosecond mtimes on transfer (patch included)

https://bugzilla.samba.org/show_bug.cgi?id=12742 Bug ID: 12742 Summary: a proposal: fix bogus nanosecond mtimes on transfer (patch included) Product: rsync Version: 3.1.1 Hardware: All OS: All

[Bug 12741] New: stop rsync on "No space left on device"

https://bugzilla.samba.org/show_bug.cgi?id=12741 Bug ID: 12741 Summary: stop rsync on "No space left on device" Product: rsync Version: 3.1.2 Hardware: x86 OS: Linux Status: NEW Severity: enhancement

[Bug 12732] hard links can cause rsync to block or to silently skip files

https://bugzilla.samba.org/show_bug.cgi?id=12732 --- Comment #1 from Hansjoerg Lipp --- Am 05.04.2017 um 22:05 schrieb L A Walsh via rsync: >I ran rsync 3.1.1 for over a year to help generate > snapshots. I can't say if it copied all the files or not, as > it was backing up

[Bug 12732] New: hard links can cause rsync to block or to silently skip files

https://bugzilla.samba.org/show_bug.cgi?id=12732 Bug ID: 12732 Summary: hard links can cause rsync to block or to silently skip files Product: rsync Version: 3.1.2 Hardware: x64 OS: Linux

<    2   3   4   5   6   7