Bug 5304 - failed to set times (symlinks)
Summary: failed to set times (symlinks)
Status: CLOSED WONTFIX
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.0
Hardware: All Mac OS X
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-05 14:52 UTC by Gabo Moreno
Modified: 2008-07-26 10:36 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 Gabo Moreno 2008-03-05 14:52:11 UTC
Hello,

Among the enhancements to version 3.0.0 you state this:

    - If we get an error setting the time on a symlink, we don't complain about
      it anymore (since some operating systems don't support that, and it's not
      that important).

However, after version 3.0.0pre7 I started getting this error:
rsync: failed to set times on "some_link_to_another_file": Permission denied (13)

where the error happens whenever the file is a soft link to a "proper" file. I know this is minor, but has me verifying perfectly successful transfers.

This is happening under MacOSX tiger, leopard, with powerpc or intel processors (does not matter), and several Linuxes with different processors, meaning something changed between pre7 and pre8 that overlooked this enhancement.

Best,
   GM
Comment 1 Wayne Davison 2008-03-05 17:22:16 UTC
The main problem is that OS X returns an inane errno, EPERM, instead of a sane one, ENOSYS.  If possible, complain to Apple's bug tracker about this issue and its kin (e.g. EPERM being returned when trying to access a extended attrs of a device, etc.).

The only error that rsync ignores these days when trying to set the time of a symlink is ENOSYS, and that will remain the same.  You can avoid the error by commenting out the HAVE_LUTIMES define (note the "L") in config.h.

Some work could be done with configure to avoid setting that define, but I'm more inclined to try to get Apple to make their functions return proper errno values.  (However, that's a soft stance, that may change.)