Bug 7621 - Special handling of lutimes ENOSYS failures does not work as intended
Summary: Special handling of lutimes ENOSYS failures does not work as intended
Status: RESOLVED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: All Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-15 00:04 UTC by Matt McCutchen
Modified: 2010-08-26 17:32 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt McCutchen 2010-08-15 00:04:47 UTC
Suppose rsync is configured with HAVE_LUTIMES=1 but is running on an older version of Linux where lutimes fails with ENOSYS.  Rsync treats the failure to set a symlink's mtime specially by itemizing "T" instead of raising exit code 23.  However, since commit accc091fe9ebbb602bcf692c577486e62011d5c1, rsync will try lutimes on non-symlinks as well and raise exit code 23, which defeats the intent of tolerating older kernels.  The same issue occurs with utimensat, support for which was added right after the aforementioned commit.

To fix this, rsync should fall back to utimes at runtime when lutimes or utimensat fails on a non-symlink.  Alternatively, the special handling of lutimes/utimensat ENOSYS failures could be removed: the need is probably less now that Linux with utimensat support has been available for three years, and the feature has always been flawed in that mtimes that rsync previously failed to set will prevent symlinks from hard-linking with --link-dest.
Comment 1 Wayne Davison 2010-08-26 17:32:54 UTC
I'm checking in a fix for this.