Hector Martin

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.

Sounds like a TOCTTOU waiting to happen

Predicting the filename is not terribly likely (it seems to use entropy from urandom). Just one of those "might break a production system somewhere some day when the stars align" things.

Ahh fair. I’m just wondering what happens if the file reappears in the middle (or can that not happen?)

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.