Re: [PATCH 05/20] rename_tmp_log(): use raceproof_create_file()

Michael Haggerty [off-list ref] writes:

Now, we have to consider the opposite case, namely that we are calling a
non-buggy implementation of `rename()`, and we artificially change
ENOTDIR to EISDIR. Can that cause any bad effects?

I don't think so, because the case where a non-buggy implementation can
yield ENOTDIR is a case, the consequent call to
`remove_dir_recursively()` would fail with ENOTDIR too, and
`raceproof_create_file()` would give up immediately.

So I think everything is OK, though I admit that it is not especially
elegant.

OK, thanks for a clear analysis.

I knew the original and the update were meant to (and would) behave
the same, but the workaround logic in the original looked iffy.