Re: [PATCH 05/20] rename_tmp_log(): use raceproof_create_file()
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 19, 2016, 17:15 UTC
- Message-ID
- <xmqq37soei5c.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <56C73DDE.1040606@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 11 quoted lines
> 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.