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:
http://www.opengroup.org/onlinepubs/007904975/functions/utime.htmlThe 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.
-jdb
-- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
