From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [git pull] vfs.git part 2 Date: Fri, 12 Jul 2013 21:02:05 +0100 Message-ID: <20130712200205.GD4165@ZenIV.linux.org.uk> References: <20130703122918.GK4165@ZenIV.linux.org.uk> <20130712054817.GY4165@ZenIV.linux.org.uk> <8738rk9eai.fsf@rasmusvillemoes.dk> <20130712154833.GA4165@ZenIV.linux.org.uk> <87wqovviyy.fsf@rasmusvillemoes.dk> <20130712191321.GB4165@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Rasmus Villemoes , Linux Kernel Mailing List , linux-fsdevel To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Jul 12, 2013 at 12:42:15PM -0700, Linus Torvalds wrote: > As to the mode argument: we should encourage people to have it, since > the inode *may* become visible afterwards. See above (can you do > linkat() to just turn an fd into a name? I didn't really check, but I > think you can do it as a "link(/proc/sef/fd/..)" thing regardless). link() won't do it, linkat() with the right arguments will (link(2) doesn't follow symlinks on the oldname). It's a bit more complicated, though: * vfs_link() will refuse to link with link count that went down to 0 (always had, and that's a damn good idea for security reasons) * with O_TMPFILE, vfs_link() will act as usual *if* you give open() O_EXCL as well - files created that way cannot be linked in, ever. They stay with link count 0 and they die as soon as they are closed. Again, that's the behaviour we'd have with O_CREAT open + unlink. tmpfile(3) ought to call it that way. * O_TMPFILE _without_ O_EXCL == you may link it in once you've decided that you've set it up enough. In that case you are supposed to open it, write whatever you want to write, fchmod/fchown/fsetxattr/etc. and use linkat() to put it in place. Or use vfs_link() if you are doing that kernel-side.