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

jw schultz jw at
Thu Dec 4 08:31:56 EST 2003

On Wed, Dec 03, 2003 at 01:03:50PM -0800, James Berry wrote:
> 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.

That is correct, thanks for pointing that out.  SUSv3 which
is the current standard (though that part of the spec is
unchanged)  A distinction is made between times setting to
current time and seting to arbitrary time where simply
having write permission is only enough for the current time.
I had missed the distinction on first pass.  It might have
been clearer had they explicitly said that write permissions
on the file do not allow seting atime or mtime to arbitrary
times.  Interesting departure from basic perms but it makes
some sense from a security standpoint.

I'm glad to see they are standards conformant on this.
Upshot is, if you want directory times preserved, be owner
or root.

As for not listing the directories, at this time the easiest
thing is grep -v '/$'.  Dirvish does something like this
because --link-dest with an empty destination and -v lists
every directory.

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list