Re: [LSF/MM/BPF TOPIC] Allowing linkat() to replace the destination

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2020-01-17 at 15:46 +0000, Al Viro wrote:
> On Fri, Jan 17, 2020 at 02:33:01PM +0000, Trond Myklebust wrote:
> > On Fri, 2020-01-17 at 12:49 +0000, David Howells wrote:
> > > It may be worth a discussion of whether linkat() could be given a
> > > flag to
> > > allow the destination to be replaced or if a new syscall should
> > > be
> > > made for
> > > this - or whether it should be disallowed entirely.
> > > 
> > > A set of patches has been posted by Omar Sandoval that makes this
> > > possible:
> > > 
> > >     
> > > https://lore.kernel.org/linux-fsdevel/cover.1524549513.git.osandov@xxxxxx/
> > > 
> > > though it only includes filesystem support for btrfs.
> > > 
> > > This could be useful for cachefiles:
> > > 
> > > 	
> > > https://lore.kernel.org/linux-fsdevel/3326.1579019665@xxxxxxxxxxxxxxxxxxxxxx/
> > > 
> > > and overlayfs.
> > > 
> > 
> > That seems to me like a "just go ahead and do it if you can justify
> > it"
> > kind of thing. It has plenty of precedent, and fits easily into the
> > existing syscall, so why do we need a face-to-face discussion?
> 
> Unfortunately, it does *not* fit easily.  And IMO that's linux-abi
> fodder more
> than anything else.  The problem is in coming up with sane semantics
> - there's
> a plenty of corner cases with that one.  What to do when destination
> is
> a dangling symlink, for example?  Or has something mounted on it (no,
> saying
> "we'll just reject directories" is not enough).  What should happen
> when
> destination is already a hardlink to the same object?
> 
> It's less of a horror than rename() would've been, but that's not
> saying
> much.

We already have precedents for all of that when handling bog-standard
open(O_CREAT) (which creates the first link to the file). Yes, there is
the question of choosing whether to implement O_NOFOLLOW semantics or
not, but that should be dictated by the requirements of the use case.

As for the "hard link on top of itself", that case is already well
defined by POSIX to be a null op IIRC.

What in the proposal is requiring new semantics beyond these precedents
already set by open() and link() itself?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx






[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux