Just a small addition: > But maybe this is something the filesystem can not guarantee at all > (w.r.t POSIX typically) ? The POSIX standard does not seem to directly address this case, but my understanding is that rename() atomicity should guarantee correct behavior w.r.t rename()/link() concurrent operations: See IEEE Std 1003.1, (1) https://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html "If the link named by the new argument exists, it shall be removed and old renamed to new. In this case, a link named new shall remain visible to other processes throughout the renaming operation and refer either to the file referred to by new or old before the operation began." "This rename() function is equivalent for regular files to that defined by the ISO C standard. Its inclusion here expands that definition to include actions on directories and specifies behavior when the new parameter names a file that already exists. That specification requires that the action of the function be atomic." (2) https://pubs.opengroup.org/onlinepubs/009695399/functions/link.html [ENOENT] "A component of either path prefix does not exist; the file named by path1 does not exist; or path1 or path2 points to an empty string." The only erroneous [ENOENT] case is when the file does not "exist"; but the renaming should guarantee that the file always "exists" ("a link named new shall remain visible to other processes throughout the renaming operation and refer either to the file referred to by new or old before the operation began") Cheers, -- Xavier Roche
