Races in llvm-objcopy

Hi Jake,

About a year ago in commit 5049c3422d26b2b68877307c41b35d7e6aae3235, you attempted to solve a race in llvm-objcopy. What was the race? I ask because unless "last change wins" is the result you want, then the race isn't solved. The problem is that `sys::fs::rename` is just a thin wrapper around POSIX semantics, and replacing an existing file is not an error.


I was able to dig up that this was reviewed in D59033, which was accidentally omitted from the commit message. But I can’t recall/find any more context that you’re looking for. (Not the author, but I reviewed it). Are you noticing race condition issues here, or just curious about the history?

Hi Jordan,

I’m looking into the fallout of a proposal I’m making to deprecate sys::path::system_temp_directory. That lead me to D59033, which then caused me to wonder what problem it was trying to solve.