rsync can't set modification time (was: rsync -vt shows directories considered?)

James Berry james at
Thu Dec 4 08:03:50 EST 2003

On Dec 3, 2003, at 12:25 PM, jw schultz wrote:
>>> Sounds like another OSX bug.
>> Indeed, it seems that the utime() call in darwin fails with EPERM if
>> the target is not owned by the caller. I'll take this up with the
>> darwin folks. The behavior (to fail for this case) matches the darwin
>> man page for  utime(), but doesn't seem to match the opengroup spec 
>> for
>> utime().
> I find this deviation from standards troubling.  My
> understanding was that they were working from a BSD codebase
> so a deviation like this means they changed system call
> behaviour without regard to standards.
> This is the sort of thing you get when application
> programmers are given commit privs on the kernel.  Instead
> of looking up the specs and fixing a broken app they
> "decide" the syscall is broken and "fix" it.  Result:
> porting nightmare--no 3rd party apps.  I'm not saying that
> is the case here, only suggesting it resembles such a case
> and I hope that isn't what has happened, or if it is they
> learn their lesson post-haste.

On the contrary, I've been told on the Darwin list that the darwin 
utime behavior _does_ conform to the POSIX standard, which basically 
says that only the owner of the file (or root) may set the date to 
anything other than the current time.

The opengroup page is here:

The interpretation that this means only the owner (or super user) can 
change the time is based on the understanding that "appropriate 
privileges" means "super user" rather than "some user that has write 
privileges via g or o". The answer to this question relies on the 
proper interpretation of that phrase.


More information about the rsync mailing list