<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 7, 2016 at 2:34 PM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Rui Ueyama via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> writes:<br>
<br>
> ruiu added a comment.<br>
><br>
> As to writing to an existing file as opposed to atomic renaming, I believe the reason why we are doing that is to not leave a corrupted file in case of crash. If you do atomic renaming, you'll get a temporary file in the worst case instead of a broken, partically-written result.<br>
><br>
> However, that can be resolved by renaming an existing file different temporary name, write to the temporary file, and then rename it back. Maybe we should do that?<br>
<br>
</span>I think the correct way to this is<br>
<br>
* Don't remove the existing file.<br>
* Create a temporary file with no name using O_TMPFILE<br>
* Use renameat to give it the correct name at the end of the link.<br>
<br>
With this we would get the following nice properties<br>
<br>
* Any other process always sees the old file or the new one.<br>
* We don't delete the old file in case of failure.<br>
* A crash or power failure will not leave a broken file around.<br>
<br>
I am not sure if renameat actually works for this, but even a<br>
unlink+linkat would be an improvement.<br></blockquote><div><br></div><div>I agree that that's the right way of doing it in the sense that it atomically replaces old file with a new result file. There's no chance that we removed a file but we didn't create a new result. However, I guess that wouldn't solve the issue that I was trying to address with this patch. Maybe the last rename takes 0.25 seconds?</div></div></div></div>