[llvm-dev] Races in llvm-objcopy

[David Zarzycki via llvm-dev]

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.

Dave

On Wed, Jun 24, 2020, at 11:35 AM, Jordan Rupprecht via llvm-dev wrote:
> 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?
> 
> On Tue, Jun 23, 2020 at 5:26 AM David Zarzycki via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 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.
>> 
>>  Dave
>>  _______________________________________________
>>  LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> 
> *Attachments:*
>  * smime.p7s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200624/28e11256/attachment.html>