https://bugzilla.samba.org/show_bug.cgi?id=7618
------- Comment #9 from the_ma...@seznam.cz 2010-08-14 16:18 CST ------- (In reply to comment #8) > Yes, I was mixed up. A Linux destination should have no trouble hard-linking > symlinks. > > New theory: the receiving rsync was configured with HAVE_LUTIMES=1, meaning > that it treats symlink mtimes as significant, but lutimes does not actually > work. This can happen if rsync was built on a kernel >= 2.6.22 but is running > on an older kernel. Under these conditions, rsync's attempt to set the mtime > of home/zumrova/.tsm in the first destination directory would fail with > ENOSYS, > which rsync would not report, and then the difference in mtime from the source > would disqualify that symlink for hard-linking. > > Can you confirm this theory by running the receiving rsync under "strace -f" > and looking for a "utimensat" call that fails with ENOSYS? > I will try it as soon as possible, but in this case, why problem occurs only when rsync server is hpux? I would expect the same behaviour with Linux rsync servers too. But no, symlinks from Linuxes are copied only once, even if in --link-dest case. Mike -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html