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.
-
That's the bug. ln -f does link(src, tmp); rename(tmp, dst); unlink(tmp). It can't just link() because that doesn't clobber; it has to unlink() because rename() is a successful noop (!) if both sides are the same inode. But if they aren't and someone re-creates tmp it gets nuked.
So there's the usual fail-safe races (e.g. if someone else collides tmp before the fact, it just fails), but there is a fail-unsafe race that might lose data, which is somewhat unexpected.
-
-
Honestly this specification for rename() is stupid. If both sides are the same inode it should just behave the same as unlink(src). That would fix the race.
-
This Tweet is unavailable.
- Show replies
New conversation -
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.