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.
-
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.
-
-
(I need to atomically exchange two hard links to the same inode or atomically overwrite a hard link with an identical hard link... if that sounds pointless, that's because it is in POSIX terms... but it isn't on CephFS due to an implementation detail!)
-
nope, vfs_rename() bails out immediately if source==target
- 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.