Re: [PATCH 1/3] lutimesat: simplify utime(2)

[Alexey Dobriyan]

On Sat, Jan 27, 2007 at 12:35:42AM +0100, Arnd Bergmann wrote:
> On Friday 26 January 2007 21:41, Andrew Morton wrote:
> > I'm somewhat surprised that this wasn't done earlier.  I wonder if there's
> > some subtle reason why this won't work.   How well tested is this?
> 
> http://www.opengroup.org/onlinepubs/000095399/functions/utimes.html
> lists a slight difference between utime and utimes in the handling
> of EPERM/EACCESS:
> 
> > The utimes() function shall fail if:
> > [EACCES] Search permission is denied by a component of the path prefix;
> >  or the times argument is a null pointer and the effective user ID of the
> >  process does not match the owner of the file and write access is denied.
> > [EPERM] The times argument is not a null pointer and the calling process'
> >  effective user ID has write access to the file but does not match the
> >  owner of the file and the calling process does not have the appropriate
> >  privileges.
> >
> > The utime() function shall fail if:
> > [EACCES]  Search permission is denied by a component of the path prefix;
> >  or the times argument is a null pointer and the effective user ID of the
> >  process does not match the owner of the file, the process does not have
> >  write permission for the file, and the process does not have appropriate
> >  privileges.
> > [EPERM] The times argument is not a null pointer and the calling process'
> >  effective user ID does not match the owner of the file and the calling
> >  process does not have the appropriate privileges.
> 
> I don't really understand how that should be implemented in different
> ways, but it might be the reason that we have separate functions.

Present sys_utime() and do_utimes() are identical, except the former
does direct getusering into new attributes, and the latter accept "int
dfd" instead of hardcoded current working directory.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/