Re: [PATCH] open: Document O_TMPFILE

["Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 01/21/2014 01:14 AM, Andy Lutomirski wrote:
> On Mon, Jan 20, 2014 at 4:52 AM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 08/07/2013 07:31 PM, Andy Lutomirski wrote:
>>> O_TMPFILE is new in Linux 3.11
>>
>> Thanks, Andy. I've applied your patch. I also added the following
>> errors under ERRORS. Do they look okay to you?
>>
>>        EINVAL O_TMPFILE  was  specified in flags, but neither O_WRONLY
>>               nor O_RDWR was specified.
>>
>>        EISDIR O_TMPFILE  and  one of O_WRONLY or O_RDWR were specified
>>               in flags, but this kernel version does not  provide  the
>>               O_TMPFILE functionality.
> 
> I suspect that EISDIR only happens if the directory exists and is
> accessible (matching the flags).  

Good point.

> Otherwise EACCES and ENOENT sound
> plausible.

Testing on older kernels, with a directory that has no permissions 
available, and a nonexistent directory, it looks like only ENOENT
comes into play (i.e., the EISDIR check is made before the EACCES 
check). So I'll add the following:

       ENOENT pathname  refers  to  a nonexistent directory, O_TMPFILE
              and one of O_WRONLY or O_RDWR were specified  in  flags,
              but  this  kernel version does not provide the O_TMPFILE
              functionality.

Look okay?

> Sigh.  Why wasn't this implemented as a brand new syscall?

Hmmm? You think it's a problem that a user of O_TMPFILE has to check for
two different error codes to see if the flag is unsupported by the kernel?

</irony>

Yes, it's a mess. Presumably, things were done this way because
other open() flags--e.g., O_CLOEXEC, O_APPEND, O_SYNC)
could be meaningfully used with tmpfiles. But it would, I imagine,
have been possible to implement those flags in a separate syscall
with some suitable refactoring to handle the pieces common to open().
I can't help but wonder if this abuse of the interface will come
back to bite us some time.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html