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

[Omar Sandoval <osandov@osandov.com>]

On Sat, Jan 18, 2020 at 02:20:32AM +0000, Al Viro wrote:
> On Fri, Jan 17, 2020 at 05:17:34PM -0800, Omar Sandoval wrote:
> > > No.  This is completely wrong; just make it ->link_replace() and be done
> > > with that; no extra arguments and *always* the same conditions wrt
> > > positive/negative.  One of the reasons why ->rename() tends to be
> > > ugly (and a source of quite a few bugs over years) are those "if
> > > target is positive/if target is negative" scattered over the instances.
> > > 
> > > Make the choice conditional upon the positivity of target.
> > 
> > Yup, you already convinced me that ->link_replace() is better in your
> > last email.
> 
> FWIW, that might be not so simple ;-/  Reason: NFS-like stuff.  Client
> sees a negative in cache; the problem is how to decide whether to
> tell the server "OK, I want normal link()" vs. "if it turns out that
> someone has created it by the time you see the request, give do
> a replacing link".  Sure, if could treat ->link() telling you -EEXIST
> as "OK, repeat it with ->link_replace(), then", but that's an extra
> roundtrip...

So that's a point in favor of ->link(). But then if we overload ->link()
instead of adding ->link_replace() and we want EOPNOTSUPP to fail fast,
we need to add something like FMODE_SUPPORTS_AT_REPLACE.

Some options I see are:

1. Go with ->link_replace() until network filesystem specs support
   AT_REPLACE. That would be a bit of a mess down the line, though.
2. Stick with ->link(), let the filesystem implementations deal with the
   positive targets, and add FMODE_SUPPORTS_AT_REPLACE so that feature
   detection remains easy for userspace.
3. Option 2, but don't bother with FMODE_SUPPORTS_AT_REPLACE.

FWIW, there is precendent for option 3: RENAME_EXCHANGE. That has the
same "files are the same" noop condition, and we don't know whether
RENAME_EXCHANGE is supported until ->rename(). A cursory search shows
that applications using RENAME_EXCHANGE try it and fall back to a
non-atomic exchange on EINVAL. They could do the exact same thing for
AT_REPLACE.

None of it is elegant, but which approach would you hate the least?