On Fri, Jan 17, 2020 at 03:54:44PM -0800, Omar Sandoval wrote: > > 3) permission checks need to be specified > > I believe the only difference here vs standard linkat is that newpath > must not be immutable or append-only? I would bloody hope not - at the very least you want sticky bit on parent to have effect, same as with rename()/rmdir()/unlink()... > > references to pathconf, Cthulhu and other equally delightful entities > > are not really welcome. > > EOPNOTSUPP is probably the most helpful. Umm... What would you feed it, though? You need to get past your "links to the same file, do nothing" escape... > Based on my previous attempt at it [1], it's not too bad. + error = may_delete(dir, new_dentry, d_is_dir(old_dentry)); Why bother with d_is_dir(), when you are going to reject directories anyway? + if (dir->i_op->link) + error = dir->i_op->link(old_dentry, dir, new_dentry); + else + error = dir->i_op->link2(old_dentry, dir, new_dentry, flags); + if (error) + goto out; + 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. And you don't need to reproduce every quirk of rename() error values. Really. Unless you really intend to have userland do a loop of linkat(2) attempts (a-la mkstemp(3)), followed by rename(2) for fallback...
