Today in POSIX surprises: `ln -f` is not *quite* atomic due to the combined semantics of link() and rename(); it racily uses a temp file and if the stars align might unlink() an identially-named temp file created by another process.
-
I've been repeatedly surprised by the number of colleagues who believe that link(2) and/or symlink(2) will atomically overwrite an existing file, without needing to unlink(2) the target and thus open the attendant race condition.
Well you can rename() over the target, and that works perfectly well for symlinks. The problem is that rename() has a stupidly defined corner case where it returns *successfully* and yet *does nothing* when both sides are the same inode. And that opens up another race.
-
-
oh, yuck. on modern linux, you could probably work around that by using renameat2() with RENAME_EXCHANGE and then always unlinking the source afterwards?
-
Ah, I was looking for something like that. Yeah, that ought to work. That might actually solve the (unrelated) use case I was trying to solve when investigating this... hmm.
- Show replies
New conversation -
-
-
This led to a hard to trace failure in a build system I once had the pleasure to experience
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.