On Fri, Jan 17, 2020 at 04:12:28PM +0000, Trond Myklebust wrote: > > 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. Where in POSIX does it say anything about it? It is a null op for rename, but for link it's EEXIST on the general grounds. > What in the proposal is requiring new semantics beyond these precedents > already set by open() and link() itself? The fact that O_CREAT does not do anything to the existing target, perhaps? This, unless I'm seriously misunderstanding the proposal, should have the preexisting link removed. Which makes it a lot more similar to "unlink target, then link source to target, atomically" than to O_CREAT. Incidentally, echo foo >/tmp/foo echo bar >/tmp/bar ln /tmp/foo /tmp/foo2 mount --bind /tmp/foo /tmp/bar echo a >/tmp/bar cat /tmp/foo2 will print "a" - IOW, O_CREAT in the redirect of that last echo will find /tmp/bar see it overmounted (by /tmp/foo) access /tmp/foo, which happens to be the same file as /tmp/foo2 What would you want that link() variant do in similar situation (i.e. mount traversal at the end of pathname)? I can see several variants of behaviour, none of them too appealing. What should happen if target is opened by somebody? I would expect it to be treated as opened-and-unlinked (with sillyrename if fs requires that). Which is where the corner case with target already being a link to source comes from... For fuck sake, I'm not being obstructionist - if you (or David, or anyone else) is willing to come up with sane semantics (I'm _not_ talking about implementation, VFS or fs data structures, etc. - just the rules describing what the effect should it have), great, I'll be happy to help with the implementation side. As well as poking holes in said proposal (i.e. asking what should happen in such and such case). But it's really _not_ as trivial as "do by analogy with O_CREAT". I don't have any problem with discussing that over email, but latencies do suck sometimes (e.g. when discussing autofs ->d_manage() semantics, with 3-way conversation - one participant on US east coast, one in UK, one on AU west coast), so I understand why David (who'd just had exactly that lovely experience) might find an idea of doing that face-to-face appealing...
