similar to: Rsync itemizing "p" even when -p, -E are off

I noticed that rsync is happy to hard-link a device node from a --link-dest dir even if its mtime differs from that of the source device node and --times is given. Is this behavior expected? It seems to break the rule that a difference in preserved attributes disqualifies a hard link. To see the behavior, run the following as root: mkdir src dest basis mknod src/null c 1 3 sleep 1 mknod

Skipped content of type multipart/alternative-------------- next part -------------- diff -urN rsync-3.0.2-orig/generator.c rsync-3.0.2/generator.c --- rsync-3.0.2-orig/generator.c 2008-03-28 10:30:11.000000000 -0700 +++ rsync-3.0.2/generator.c 2008-05-07 15:35:08.317364774 -0700 @@ -1508,6 +1508,7 @@ if (preserve_links && S_ISLNK(file->mode)) { #ifdef SUPPORT_LINKS + int iflags =

Similar to --omit-{dir,link}-times: --omit-device-times omit device files from --times --omit-special-times omit sockets and fifos from --times Also, fix corner case that allows --omit-dir-times to be ignored. See unchanged_attrs() and recv_generator()'s call to try_dests_non(). Marc. diff -aNpRruz -X /etc/diff.excludes rsync-3.2.7/generator.c devel-3.2.7/generator.c ---

https://bugzilla.samba.org/show_bug.cgi?id=5645 Summary: Optimization-only basis dirs that don't affect itemization Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned@samba.org

IIUC, the new philosophy of symlink times is that -t preserves them to the extent that they are settable; when they aren't, it's just as if -t wasn't given. But rsync breaks this principle in the following case. Suppose rsync is configured with HAVE_LUTIMES enabled but the lutimes call doesn't actually work (I simulated this via the attached patch). When rsync recreates a

https://bugzilla.samba.org/show_bug.cgi?id=7622 Summary: Factor out common logic from itemize and unchanged_attrs functions Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned at samba.org

A while ago (2.6.2), I built and posted a patch which caused rsync to "do the right thing" where --link-dest was being used and where files had been changed only in their ACLs. I've recreated this for 2.6.8 (there were some small differences). I've tested this using --link-dest copying from Linux-Linux and Linux-Solaris. I plan to test Solaris-Solaris too, of course. But

https://bugzilla.samba.org/show_bug.cgi?id=8073 Summary: Regress: 3.0.8 cannot compile on freebsd Product: rsync Version: 3.0.8 Platform: x86 OS/Version: FreeBSD Status: NEW Severity: blocker Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: grarpamp at gmail.com

Hi, first of all, sorry for taking so long. Unfortunately, some other tasks kept coming up. Anyway, attached is the version of the flags patch, that is based on the one I'm using with 2.6.9. It is against the rsync-3.0.0pre9 release. I've included the option name change from the repository, so the option is now called --fileflags. Improved from the previously distributed version is the

https://bugzilla.samba.org/show_bug.cgi?id=8268 Summary: Wrong unchanged_attrs test for symlink ownership Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: matt at

https://bugzilla.samba.org/show_bug.cgi?id=4561 ------- Comment #1 from matt@mattmccutchen.net 2007-11-04 14:51 CST ------- Created an attachment (id=2960) --> (https://bugzilla.samba.org/attachment.cgi?id=2960&action=view) Implementation of --tweak options Here, finally, is an implementation of the --tweak options! Now that bug 5051 and the omission of mtimes from unchanged_attrs

https://bugzilla.samba.org/show_bug.cgi?id=5644 Summary: Option to recheck basis dirs for existing dest files Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy:

https://bugzilla.samba.org/show_bug.cgi?id=7618 Summary: symlinks and --link-dest Product: rsync Version: 3.0.7 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at samba.org ReportedBy: the_majkl at seznam.cz QAContact:

Hi, below you find a patch fixing a bug in the file comparison code: The current code skips the unchanged_file() check when that check succeeded for an earlier candidate, which could lead to accepting a file with a different checksum as unchanged, for example. Please be aware that the patch is untested. Florian diff --git a/generator.c b/generator.c index a112da6..2df1b28 100644 ---

https://bugzilla.samba.org/show_bug.cgi?id=5287 Summary: FreeBSD pre10 compilation warnings report Product: rsync Version: 3.0.0 Platform: x86 OS/Version: FreeBSD Status: NEW Severity: minor Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: 14709c93@mailinator.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, opensuse 13.2 linux v3.16.7-7-desktop x86_64 rsync v3.1.1 I used rsync to copy /usr/ to another volume with these options: - --recursive --one-file-system --links --stats --itemize-changes - --quiet --delete --times After I had modified the system to use the new /usr volume, I realized I should have added: - --perms --owner --group

https://bugzilla.samba.org/show_bug.cgi?id=12036 Bug ID: 12036 Summary: Multiple --link-dest, --copy-dest, or --compare-dest flags produce incorrect behavior Product: rsync Version: 3.1.2 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Normally, I would say that --checksum is actually slower than just letting rsync re-copy everything and therefore is almost always the wrong thing to do. However, in this case, you really don't want to overwrite the running OS even with files that are essentially the same. So, if the system is running from that storage then --checksum might

On 08/02/2017 07:36 AM, hw wrote: > > Don?t get me started on Fedora updates. One of the reasons to deprecate > Fedora was that upgrading had turned out to be unreliable and mostly > failing. Not being able to reliably upgrade disqualifies any > distribution. I hate to break it to you, but since they began using fedup and dnf upgrade, it's never been an issue for me at

On Tue, Oct 12, 2010 at 1:21 PM, leledumbo <leledumbo_cool at yahoo.co.id> wrote: > >> only if the compiler can prove that the called function has >> no side effects (such as modifying some global variables or >> causing the program to exit). > > can it prove if the function resides in a shared library? Only if the right function attributes are added. See