rsync can't set modification time (was: rsync -vt shows
james at jberry.us
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
> 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