| Re: [PATCH 1/3] lutimesat: simplify utime(2) [message #9897 is a reply to message #9878] |
Sun, 28 January 2007 15:28   |
Alexey Dobriyan
Messages: 195
Registered: August 2006
|
Senior Member |
|
|
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/utim es.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.
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
