rsync - Aug 2010 - DO NOT REPLY [Bug 7618] New: symlinks and --link-dest

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: rsync-qa at samba.org


Rsync creates/reports(?) new symlinks instead of using old ones in linked
directory.

## first rsync creates hpuh directory:

[root at zaloha pokus]# rsync  -avz  --exclude-from=hpuh.conf --delete-before
--delete-excluded --numeric-ids -8 --password-file=/etc/rsync.secrets
rsync://backup at hpuh/system hpuh              receiving file list ... done
created directory hpuh
./
home/
home/zumrova/
home/zumrova/.private
home/zumrova/.profile
home/zumrova/.tsm -> /usr/tsm/.tsm
home/zumrova/mu
home/zumrova/.lpuser/
home/zumrova/.lpuser/global.log

sent 319 bytes  received 1008 bytes  2654.00 bytes/sec
total size is 1229  speedup is 0.93

--> ok, as expected

## second transfer for check:

[root at zaloha pokus]# rsync  -avz  --exclude-from=hpuh.conf --delete-before
--delete-excluded --numeric-ids -8 --password-file=/etc/rsync.secrets
rsync://backup at hpuh/system hpuh
receiving file list ... done

sent 228 bytes  received 274 bytes  334.67 bytes/sec
total size is 1229  speedup is 2.45

-> ok, nothing new, symlink .tsm is not reported/created

# let's move the folder and use it as link destination

[root at zaloha pokus]# mv hpuh hpuh1
[root at zaloha pokus]# rsync  -avz  --exclude-from=hpuh.conf --delete-before
--delete-excluded --numeric-ids  -8 --password-file=/etc/rsync.secrets
--link-dest=/root/pokus/hpuh1/ rsync://backup at hpuh/system hpuh
receiving file list ... done
created directory hpuh
home/zumrova/.tsm -> /usr/tsm/.tsm

sent 231 bytes  received 277 bytes  1016.00 bytes/sec
total size is 1229  speedup is 2.42
[root at zaloha pokus]#

-> symbolic link(s) seems to be recreated/reported as new, why? But only when
linking to moved/renamed directory.

##  client (linux):
rsync  version 3.0.7  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, no symtimes

## server (hpuh 11.23)
rsync  version 3.0.7  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 32-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace,
    append, ACLs, no xattrs, iconv, no symtimes


Thanks, 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.

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #1 from the_majkl at seznam.cz  2010-08-13 06:53 CST
-------
> ## server (hpuh 11.23)
Eh, hpux 11.23. 


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #2 from matt at mattmccutchen.net  2010-08-14 02:19 CST -------
(In reply to comment #0)
> -> symbolic link(s) seems to be recreated/reported as new, why? But only
when
> linking to moved/renamed directory.
Is your OS capable of hard-linking symlinks?  Check the value of
CAN_HARDLINK_SYMLINK in config.h when you build rsync.


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

https://bugzilla.samba.org/show_bug.cgi?id=7618


the_majkl at seznam.cz changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |the_majkl at seznam.cz




------- Comment #3 from the_majkl at seznam.cz  2010-08-14 02:40 CST -------
(In reply to comment #2)
> (In reply to comment #0)
> > -> symbolic link(s) seems to be recreated/reported as new, why? But
only when
> > linking to moved/renamed directory.
> 
> Is your OS capable of hard-linking symlinks?  Check the value of
> CAN_HARDLINK_SYMLINK in config.h when you build rsync.
> 
I installed it from binary package (on both sides), so I can not check it. But
this behaviour occurs only when rsyncing against hp-ux rsync server - none of
another 8 linux servers shows (the same client, of course) symlinks again and
again and I believe there are some symlinks, too :-)

Thanks, 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.

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #4 from matt at mattmccutchen.net  2010-08-14 02:49 CST -------
(In reply to comment #3)
> (In reply to comment #2)
> > Is your OS capable of hard-linking symlinks?  Check the value of
> > CAN_HARDLINK_SYMLINK in config.h when you build rsync.
> 
> I installed it from binary package (on both sides), so I can not check it.
You can also do the test by hand:

$ ln -s nonexistent broken
$ ln broken broken2

If that fails, rsync assumes that link(2) follows symlinks in its first
argument and therefore does not try to hard-link symlinks.


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #5 from the_majkl at seznam.cz  2010-08-14 04:04 CST -------
(In reply to comment #4)
> 
> You can also do the test by hand:
> 
> $ ln -s nonexistent broken
> $ ln broken broken2
> 
# ln -s nonexistent broken
# ln broken broken2
# ll non* brok*
ls: non*: No such file or directory
lrwxrwxrwx 2 root root 11 Aug 14 11:01 broken -> nonexistent
lrwxrwxrwx 2 root root 11 Aug 14 11:01 broken2 -> nonexistent
#


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.

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #6 from matt at mattmccutchen.net  2010-08-14 15:28 CST -------
(In reply to comment #5)
> (In reply to comment #4)
> > 
> > You can also do the test by hand:
> > 
> > $ ln -s nonexistent broken
> > $ ln broken broken2
> > 
> 
> # ln -s nonexistent broken
> # ln broken broken2
> # ll non* brok*
> ls: non*: No such file or directory
> lrwxrwxrwx 2 root root 11 Aug 14 11:01 broken -> nonexistent
> lrwxrwxrwx 2 root root 11 Aug 14 11:01 broken2 -> nonexistent
Was that on the HP-UX server?  If so, then it's strange that the rsync
package
you installed was not configured to hard-link symlinks, but there's nothing
we
can do about third-party packages.  If you build your own rsync and it still
doesn't want to hard-link symlinks, we can look into why.


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #7 from the_majkl at seznam.cz  2010-08-14 15:44 CST -------
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > 
> > > You can also do the test by hand:
> > > 
> > > $ ln -s nonexistent broken
> > > $ ln broken broken2
> > > 
> > 
> > # ln -s nonexistent broken
> > # ln broken broken2
> > # ll non* brok*
> > ls: non*: No such file or directory
> > lrwxrwxrwx 2 root root 11 Aug 14 11:01 broken -> nonexistent
> > lrwxrwxrwx 2 root root 11 Aug 14 11:01 broken2 -> nonexistent
> 
> Was that on the HP-UX server?  If so, then it's strange that the rsync
package
> you installed was not configured to hard-link symlinks, but there's
nothing we
> can do about third-party packages.  If you build your own rsync and it
still
> doesn't want to hard-link symlinks, we can look into why.
> 
No no, this was on the client side, on backup server (linux).
Once again, rsync works as expected/needed, it copy symlinks (from hpux) as
symlinks (to linux). Look one more time on the first posting ("second
transfer
for check" did not report new symlink). But WHEN I MOVE the synced
directory
(on linux) AND LINK (--link-dest) another rsync backup into it, the symlinks
are copied/reported as changed/new/anything. 

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.

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #8 from matt at mattmccutchen.net  2010-08-14 16:11 CST -------
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?


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #9 from the_majkl at 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.

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #10 from matt at mattmccutchen.net  2010-08-14 16:32 CST -------
(In reply to comment #9)
> 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.
Good point.  That would appear to rule out a broken lutimes.

Please pass -i to find out why the symlink is not hard-linked when pulling from
the HP-UX server.  (I really should have suggested this the first time around,
before starting to speculate.)


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #11 from the_majkl at seznam.cz  2010-08-14 16:42 CST -------
Ok, when -i added as rsync parameter.

root at zaloha pokus]# grep .tsm rsync3.traced
[pid  9438] lstat("home/zumrova/.tsm", 0x7fffba96ea10) = -1 ENOENT (No
such
file or directory)
[pid  9438] lstat("/root/pokus/hpuh1/home/zumrova/.tsm",
{st_mode=S_IFLNK|0777,
st_size=13, ...}) = 0
[pid  9438] readlink("/root/pokus/hpuh1/home/zumrova/.tsm",
"/usr/tsm/.tsm",
4095) = 13
[pid  9438] lstat("/root/pokus/hpuh1/home/zumrova/.tsm",
{st_mode=S_IFLNK|0777,
st_size=13, ...}) = 0
[pid  9438] symlink("/usr/tsm/.tsm", "home/zumrova/.tsm") =
0
[pid  9438] lstat("home/zumrova/.tsm", {st_mode=S_IFLNK|0777,
st_size=13, ...})
= 0
[pid  9438] lchown("home/zumrova/.tsm", 0, 3) = 0
[pid  9439] write(1, "cLc.T...... home/zumrova/.tsm ->"...,
47cLc.T......
home/zumrova/.tsm -> /usr/tsm/.tsm


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #12 from the_majkl at seznam.cz  2010-08-14 16:46 CST -------
And straces when without -i:

First run: 
root at zaloha pokus]# grep .tsm rsync1.traced
[pid  9169] lstat("home/zumrova/.tsm", 0x7fff2ff0e040) = -1 ENOENT (No
such
file or directory)
[pid  9169] symlink("/usr/tsm/.tsm", "home/zumrova/.tsm") =
0
[pid  9169] lstat("home/zumrova/.tsm", {st_mode=S_IFLNK|0777,
st_size=13, ...})
= 0
[pid  9169] lchown("home/zumrova/.tsm", 0, 3) = 0
[pid  9170] write(1, "home/zumrova/.tsm -> /usr/tsm/.t"...,
35home/zumrova/.tsm
-> /usr/tsm/.tsm

# mv hpuh hpuh1

second run, with --link-dest:

[root at zaloha pokus]# grep .tsm rsync2.traced
[pid  9426] lstat("/root/pokus/hpuh1/home/zumrova/.tsm",
{st_mode=S_IFLNK|0777,
st_size=13, ...}) = 0
[pid  9426] readlink("/root/pokus/hpuh1/home/zumrova/.tsm",
"/usr/tsm/.tsm",
4095) = 13
[pid  9426] lstat("/root/pokus/hpuh1/home/zumrova/.tsm",
{st_mode=S_IFLNK|0777,
st_size=13, ...}) = 0
[pid  9427] write(1, "home/zumrova/.tsm -> /usr/tsm/.t"...,
35home/zumrova/.tsm
-> /usr/tsm/.tsm
[root at zaloha pokus]#


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #13 from the_majkl at seznam.cz  2010-08-14 16:52 CST -------
Sorry, mistake:

Second run with --lin-dest
[root at zaloha pokus]# grep .tsm rsync2.traced
[pid  9473] lstat("home/zumrova/.tsm", 0x7fffd42da910) = -1 ENOENT (No
such
file or directory)
[pid  9473] lstat("/root/pokus/hpuh1/home/zumrova/.tsm",
{st_mode=S_IFLNK|0777,
st_size=13, ...}) = 0
[pid  9473] readlink("/root/pokus/hpuh1/home/zumrova/.tsm",
"/usr/tsm/.tsm",
4095) = 13
[pid  9473] lstat("/root/pokus/hpuh1/home/zumrova/.tsm",
{st_mode=S_IFLNK|0777,
st_size=13, ...}) = 0
[pid  9473] symlink("/usr/tsm/.tsm", "home/zumrova/.tsm") =
0
[pid  9473] lstat("home/zumrova/.tsm", {st_mode=S_IFLNK|0777,
st_size=13, ...})
= 0
[pid  9473] lchown("home/zumrova/.tsm", 0, 3) = 0
[pid  9474] write(1, "home/zumrova/.tsm -> /usr/tsm/.t"...,
35home/zumrova/.tsm
-> /usr/tsm/.tsm


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #14 from the_majkl at seznam.cz  2010-08-14 17:20 CST -------
I created .tsm on one one Linux rsync servers, rsynced, moved and rsynced with
--link-dest:

[root at zaloha pokus]# grep .tsm rsync2_samba.traced
[pid  9576] lstat("home/zumrova/.tsm", 0x7fff66893b80) = -1 ENOENT (No
such
file or directory)
[pid  9576] lstat("/root/pokus/hpuh1/home/zumrova/.tsm",
{st_mode=S_IFLNK|0777,
st_size=13, ...}) = 0
[pid  9576] readlink("/root/pokus/hpuh1/home/zumrova/.tsm",
"/usr/tsm/.tsm",
4095) = 13
[pid  9576] lstat("/root/pokus/samba1/home/zumrova/.tsm",
{st_mode=S_IFLNK|0777, st_size=13, ...}) = 0
[pid  9576] readlink("/root/pokus/samba1/home/zumrova/.tsm",
"/usr/tsm/.tsm",
4095) = 13
[pid  9576] link("/root/pokus/samba1/home/zumrova/.tsm",
"home/zumrova/.tsm") 0
[root at zaloha pokus]#

Hardlink creation can be seen here. 


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #15 from the_majkl at seznam.cz  2010-08-14 17:26 CST -------
Eh, too late night for me. Once again, the same sutuation but againts one of
linux servers:

[root at zaloha pokus]# grep .tsm rsync2_samba.traced
[pid  9587] lstat("home/zumrova/.tsm", 0x7fffd0d1e480) = -1 ENOENT (No
such
file or directory)
[pid  9587] lstat("/root/pokus/samba1/home/zumrova/.tsm",
{st_mode=S_IFLNK|0777, st_size=13, ...}) = 0
[pid  9587] readlink("/root/pokus/samba1/home/zumrova/.tsm",
"/usr/tsm/.tsm",
4095) = 13
[pid  9587] link("/root/pokus/samba1/home/zumrova/.tsm",
"home/zumrova/.tsm") 0
[root at zaloha pokus]#


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #16 from matt at mattmccutchen.net  2010-08-14 23:26 CST -------
I just noticed the "no symtimes" (i.e., HAVE_LUTIMES off) in the
"rsync
--version" output for the client in comment #0.  Consistent with that,
rsync
does not attempt to set the symlink's mtime in the first log in comment #12.
So the problem must be elsewhere.

Next theory: It looks like symlinks on HP-UX can have permissions other than
777, according to a discussion
(http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1281845702588+28353475&threadId=956122)
I found by searching Google for "hp-ux symlink permission".  And it
looks like
rsync (in unchanged_attrs) will consider a difference in permissions of a
symlink to disqualify it for hard-linking, even if rsync is unable to set
symlink permissions (HAVE_LCHMOD off).  What are the permissions of
home/zumrova/.tsm on the HP-UX source?


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #17 from the_majkl at seznam.cz  2010-08-15 03:58 CST -------
(In reply to comment #16)
> I just noticed the "no symtimes" (i.e., HAVE_LUTIMES off) in the
"rsync
> --version" output for the client in comment #0.  Consistent with that,
rsync
> does not attempt to set the symlink's mtime in the first log in comment
#12.
> So the problem must be elsewhere.
> 
> Next theory: It looks like symlinks on HP-UX can have permissions other
than
> 777, according to a discussion
>
(http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1281845702588+28353475&threadId=956122)
> I found by searching Google for "hp-ux symlink permission".  And
it looks like
> rsync (in unchanged_attrs) will consider a difference in permissions of a
> symlink to disqualify it for hard-linking, even if rsync is unable to set
> symlink permissions (HAVE_LCHMOD off).  What are the permissions of
> home/zumrova/.tsm on the HP-UX source?
> 
hpuh:/home/zumrova # ls -l .tsm
lrwxr-xr-x   1 root       sys             13 Mar 23  2006 .tsm ->
/usr/tsm/.tsm

(and for info
hpuh:/home/zumrova # ls -l /usr/tsm/.tsm
-r--r--r--   1 hajek      sys           4253 Mar  6  2001 /usr/tsm/.tsm
)

But then I would expect rsync to consider the symlink changed every time, not
only when running with --link-dest.

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.

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #18 from the_majkl at seznam.cz  2010-08-15 04:05 CST -------
And on hp-ux 
chmod  blahblah /home/zumrova/.tsm 
changes permissions on the real file, the symlink permissions stays unchanged.

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.

https://bugzilla.samba.org/show_bug.cgi?id=7618


matt at mattmccutchen.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|symlinks and --link-dest    |Symlink permissions
                   |                            |disqualify --link-dest even
                   |                            |when they can't be set




------- Comment #19 from matt at mattmccutchen.net  2010-08-15 12:37 CST -------
(In reply to comment #17)
> hpuh:/home/zumrova # ls -l .tsm
> lrwxr-xr-x   1 root       sys             13 Mar 23  2006 .tsm ->
/usr/tsm/.tsm
So that's it.  Unfortunately, the only workarounds I can offer are to
exclude
the symlink or recreate it on the source with 777 permissions by setting your
umask to 0.
> But then I would expect rsync to consider the symlink changed every time,
not
> only when running with --link-dest.
I should have been clearer.  Treating differences in symlink permissions as
significant even on systems where they can't be set is not the expected
behavior, it is a bug specific to --link-dest.


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #20 from the_majkl at seznam.cz  2010-08-15 13:42 CST -------
(In reply to comment #19)
> (In reply to comment #17)
> > hpuh:/home/zumrova # ls -l .tsm
> > lrwxr-xr-x   1 root       sys             13 Mar 23  2006 .tsm ->
/usr/tsm/.tsm
> 
> So that's it.  Unfortunately, the only workarounds I can offer are to
exclude
> the symlink or recreate it on the source with 777 permissions by setting
your
> umask to 0.
> 
> > But then I would expect rsync to consider the symlink changed every
time, not
> > only when running with --link-dest.
> 
> I should have been clearer.  Treating differences in symlink permissions as
> significant even on systems where they can't be set is not the expected
> behavior, it is a bug specific to --link-dest.
> 
That's my opinion too :-) Is it a known bug? Will it be fixed in new
version?

Very thanks, 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.

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #21 from matt at mattmccutchen.net  2010-08-15 14:14 CST -------
(In reply to comment #20)
> Is it a known bug?
It is a known bug now, by virtue of you having reported it and me having
diagnosed it.
> Will it be fixed in new version?
Probably, but I cannot make any guarantees.


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #22 from the_majkl at seznam.cz  2010-11-26 03:48 CST -------
Hi, 

any news about this problem? No patch yet, or something else?

Thanks, 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.

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #23 from wayned at samba.org  2010-11-26 12:31 CST -------
Created an attachment (id=6091)
 --> (https://bugzilla.samba.org/attachment.cgi?id=6091&action=view)
Make unchanged_attrs() skip unsettable symlink attrs.

This patch is relative to the 3.1.0dev trunk.


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #24 from wayned at samba.org  2010-11-26 12:32 CST -------
Created an attachment (id=6092)
 --> (https://bugzilla.samba.org/attachment.cgi?id=6092&action=view)
Make unchanged_attrs() skip unsettable symlink attrs.

This patch applies to 3.0.7.


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

https://bugzilla.samba.org/show_bug.cgi?id=7618





------- Comment #25 from the_majkl at seznam.cz  2010-12-07 00:44 CST -------
Tested 3.0.7 + the patch, looks good, really thanks :-)

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.

https://bugzilla.samba.org/show_bug.cgi?id=7618

Wayne Davison <wayned at samba.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #26 from Wayne Davison <wayned at samba.org> 2011-06-04
20:08:28 UTC ---
This was fixed in 3.0.8 (using slightly different code than the attached
patches).

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.