Re: [PATCH 5/6] Makefile: use "ln -f" instead of "rm && ln"

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 29, 2021, 22:46 UTC
Message-ID: <xmqqim59h93j.fsf@gitster.g>
In-Reply-To: <patch-5.7-f81708f6120-20210329T162327Z-avarab@gmail.com>

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

Show 7 quoted lines

> 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.