From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: linux-kernel@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [git pull] vfs.git part 2
Date: Fri, 12 Jul 2013 12:02:45 +0000 [thread overview]
Message-ID: <8738rk9eai.fsf@rasmusvillemoes.dk> (raw)
In-Reply-To: 20130712054817.GY4165@ZenIV.linux.org.uk
Al Viro <viro@ZenIV.linux.org.uk> writes:
> On Thu, Jul 11, 2013 at 02:42:54PM -0700, Linus Torvalds wrote:
>> But with an *old* kernel, O_TMPFILE will just silently be ignored as
>> an unrecognized flag, and things won't work. If you do
>>
>> fd = open("dirname", O_CREAT | O_TMPFILE | O_RDWR, 0666);
>>
>> it may be that it ends up acting as a "create file at specified
>> directory path" instead of what the user *meant* for it to do, which
>> was "create unnamed temporary file in the specified directory".
>>
>
> It's slightly less painful than that - if dirname exists, the old kernels
> will fail; O_CREAT for existing directory means an error.
But isn't the problem the case where dirname does not exist? I.e., the
application has to make sure that "/some/where" exists and is a directory
before open("/some/where", O_CREAT | O_TMPFILE | O_RDWR, 0666) can be
relied upon to fail on kernels not recognizing O_TMPFILE, instead of
just creating "where" in "/some".
Just thinking out loud, and please tell me to shut up if it doesn't make
sense: The documentation for O_DIRECTORY seems to imply that one could
require O_DIRECTORY to be given when using O_TMPFILE. The "If pathname
is not a directory, cause the open to fail" certainly seems to make
sense when O_TMPFILE is used, and older kernels should complain when
seeing the O_CREAT|O_DIRECTORY combination. It is a hack, though.
Rasmus
next prev parent reply other threads:[~2013-07-12 12:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-03 12:29 [git pull] vfs.git part 2 Al Viro
2013-07-11 21:42 ` Linus Torvalds
2013-07-12 5:48 ` Al Viro
2013-07-12 11:54 ` Al Viro
2013-07-12 12:02 ` Rasmus Villemoes [this message]
2013-07-12 15:48 ` Al Viro
2013-07-12 16:30 ` Rasmus Villemoes
2013-07-12 19:13 ` Al Viro
2013-07-12 19:39 ` Al Viro
2013-07-12 20:21 ` Linus Torvalds
2013-07-12 21:16 ` Al Viro
2013-07-15 23:13 ` Rasmus Villemoes
2013-07-12 19:42 ` Linus Torvalds
2013-07-12 20:02 ` Al Viro
2017-07-05 7:14 Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8738rk9eai.fsf@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.