On Mon, 19 Sep 2022, Christian Brauner wrote: > On Fri, Sep 16, 2022 at 05:32:45PM +0300, Amir Goldstein wrote: > > On Fri, Sep 16, 2022 at 9:26 AM NeilBrown <neilb@xxxxxxx> wrote: > > > > > > > > > rename(2) is documented as > > > > > > If newpath already exists, it will be atomically replaced, so > > > that there is no point at which another process attempting to > > > access newpath will find it missing. > > > > > > However link(2) from a given path can race with rename renaming to that > > > path so that link gets -ENOENT because the path has already been unlinked > > > by rename, and creating a link to an unlinked file is not permitted. > > > > > > > I have to ask. Is this a real problem or just a matter of respecting > > the laws of this man page? > > I have to say that I have the same reaction. The commit message doesn't > really explain where the current behavior becomes an issue and whether > there are any users seeing issues with this. And the patch makes > do_linkat() way more complex than it was before. > A bug is a bug .... and in this case it is an intriguing puzzle too. Yes, the commit message could say a bit more about context. The patch also isn't correct, so the complexity is not relevant in this case. Some complexity will likely been needed (I do have a really simple patch that just retries the whole op, but I don't think that is safe), and we do need to balance the complexity against the value. Ideally we could end up making the code simpler ... I'm not sure I can manage that though :-) Thanks, NeilBrown
