Description of problem:
rsync gives the following error for every symlink that gets rsynced:
rsync: failed to set times on "some_symlink": Function not implemented (38)

Apparently, rsync tries to set the time of the symlink (use option -a (archive)
to achieve this behaviour), but that doesn't work. Hence the error.

I found this bugreport on the same issue:
http://www.nabble.com/rsync:-failed-to-set-times-on-symbolic-links-t4801955.html

The interesting part:
[quote]I'm pretty sure it's not posix, but there's a new (at least to linux)
function called lutimes() which does set the time on a symlink.  I know
the kernel support (utimesat) was added in linux-2.6.22.  I'm not clear
on when the function was added to glibc.

It seems Charles' problem was that he built rsync on one system (which
probably had a newer glibc), and ran it on another where the lutimes()
function failed.[/quote]

I think this is the same problem that I run into. 
Fedora 8 comes with a 2.6.23 kernel, but the XEN build is still equipped with a
2.6.21 kernel. I assume rsync is built on the 2.6.23 kernel, which explains why
it won't run correctly on the 2.6.21 XEN build.

Version-Release number of selected component (if applicable):
kernel-xen-2.6.21-2950.fc8
rsync-2.6.9-3.2.fc8
rsnapshot-1.3.0-1.fc8
All on x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install Fedora 8 with XEN
2. Start an rsync to your box from a source which contains symlinks, for
instance: rsync -a root@box:/ .
3. Observe the abovementioned error message for every symlink that gets rsynced

Actual results:
rsync: failed to set times on "some_symlink": Function not implemented (38)

Expected results:
No error message. 

The symlink gets rsynced correctly, but the date isn't set correctly. In non-XEN
Fedora 8 this date apparently does get set right, so I suppose it's reasonable
to expect it to work in XEN as well.
However, for me the problem would also be sufficiently solved without actually
setting the date/time right, as long as the error message disappears.

Additional info:
The reason why this is a problem for me is that rsync returns an error code,
thereby causing rsnapshot to detect the failure and thus ruining the backup.
If rsync would simply quietly ignore the errors, or not attempt to set the
date/time at all, it would all be great.
So I suppose building the rsync package against a 2.6.21 kernel would probably
solve the issue for me, but I imagine that the better solution would be to
update the XEN package to 2.6.23 or at least include that one missing call.