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.
-
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
-
Meh. Wonder if libcephfs does the same check of if it'll fly there. My current best plan is link(src, tmp); symlink(tmp, tmp2); rename(tmp2, src); stat(other_hardlink); rename(tmp, src);. Involves a temporary symlink but should keep src accessible while doing what I want.
End of conversation
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.