Michael Haggerty <mhag...@alum.mit.edu> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
