[PATCH] D27295: Remove existing file in a separate thread asynchronously.

[Rui Ueyama via llvm-commits]

On Wed, Dec 7, 2016 at 2:34 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> Rui Ueyama via Phabricator <reviews at reviews.llvm.org> writes:
>
> > ruiu added a comment.
> >
> > 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.
> >
> > 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?
>
> I think the correct way to this is
>
> * Don't remove the existing file.
> * Create a temporary file with no name using O_TMPFILE
> * Use renameat to give it the correct name at the end of the link.
>
> With this we would get the following nice properties
>
> * Any other process always sees the old file or the new one.
> * We don't delete the old file in case of failure.
> * A crash or power failure will not leave a broken file around.
>
> I am not sure if renameat actually works for this, but even a
> unlink+linkat would be an improvement.
>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161207/fd893037/attachment.html>