Bug 399971 - rsync doesn't work correctly on XEN host
rsync doesn't work correctly on XEN host
Product: Fedora
Classification: Fedora
Component: rsync (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Simo Sorce
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-11-26 14:13 EST by Erik Logtenberg
Modified: 2009-01-09 00:20 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-09 00:20:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Erik Logtenberg 2007-11-26 14:13:19 EST
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:

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):
All on x86_64

How reproducible:

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.
Comment 1 Erik Logtenberg 2007-11-26 14:24:05 EST
I found some additional information on this same issue:


Here it is suggested that the lutimes() function is FS-specific, so I suppose it
might be relevant to say that I'm using XFS for these backups. If I could work
around this issue by changing to another FS, that could perhaps be possible.
However some quick tests don't seem promising..

Anyway, according to those guys rsync 3.0 doesn't report these errors at all, so
an upgrade to rsync 3.0 would also probably fix this issue for me. Perhaps it's
possible to backport the responsible piece of code?

Comment 2 Bug Zapper 2008-11-26 03:42:22 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 3 Bug Zapper 2009-01-09 00:20:37 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.