Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > Change the invocations and behavior of "ln-or-cp.sh" to not assume > that we're going to "rm" the file in question beforehand. > > This reduces the complexity of these rules, and as a bonus means it's > now safe to "make install" on a system that may have running "git" > programs, before this we'd be racing the "rm && ln/cp" and wouldn't > have a working "git" (or one of the built-ins) in the interim. Neither link(2) nor symlink(2) has the equivalent of the -f flag, so "ln [-s] -f" has to be implemented as an unlink(2) followed by link(2) or symlink(2) anyway, so you didn't solve the "racing" problem (if that is a problem in the first place, that is), did you? The only reason why "rm -f t && ln s t" makes sense over "ln -f s t" is because there could be a leftover 't' directory from a previous build or rogue testing process or whatever. It avoids creating a hardlink at t/s, unlike "ln -f s t" which would happily do so. It would let us notice there is something fishy going on by failing to remove the stray directory that should not exist. I do not object to replace "rm then ln" with "ln -f", as the "be cautious against somebody mistakenly making a directory there" is not something I find valuable all that much. But I do not want to be associated with a commit that claims that "ln -f" avoids race in "rm && ln" ;-). Thanks.
