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, 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...

Hell knows...  I would really like to avoid any kind of ->atomic_open()
redux ;-/



[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