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? If we manage to return EBUSY in that case to link(2) will everyone be happy and we can avoid trying to make link(2) atomic w.r.t. rename(2)? Thanks, Amir.
