[PATCH] localedata: Avoid concurrently written locales in gen-locale.sh

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 08/07/26 09:03, Florian Weimer wrote:
>> There is no cross-directory exclusion of concurrent $(gen-locales)
>> usage.  Parallel localedef calls can clobber locale data as it is
>> being loaded by tests.
>> 
>> With --no-hard-links, the separate touch invocation is no longer
>> required.
>
> LGTM, thanks.
>
> Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

Thanks.

>> ---
>>  localedata/gen-locale.sh | 22 +++++++++++++++-------
>>  1 file changed, 15 insertions(+), 7 deletions(-)
>> 
>> diff --git a/localedata/gen-locale.sh b/localedata/gen-locale.sh
>> index 4762c04284..b0ce27fbae 100644
>> --- a/localedata/gen-locale.sh
>> +++ b/localedata/gen-locale.sh
>> @@ -32,15 +32,23 @@ generate_locale ()
>>    out=$3
>>    flags=$4
>>    ret=0
>> +
>> +  # Use a staging area to avoid writing to locales concurrently.
>> +  # While this process is running, $$ is sufficiently unique.
>> +  # Use --no-hard-links to prevent localedef from accessing
>> +  # other staging areas.
>> +  stage="${common_objpfx}localedata/gen-locale.$$.tmp"
>> +
>>    ${localedef_before_env} ${run_program_env} I18NPATH=../localedata \
>> -	${localedef_after_env} $flags -f $charmap -i $input \
>> -	${common_objpfx}localedata/$out || ret=$?
>> -  if [ $ret -eq 0 ]; then
>> -    # The makefile checks the timestamp of the LC_CTYPE file,
>> -    # but localedef won't have touched it if it was able to
>> -    # hard-link it to an existing file.
>> -    touch ${common_objpfx}localedata/$out/LC_CTYPE
>> +	${localedef_after_env} $flags --no-hard-links -f $charmap -i $input \
>> +	$stage || ret=$?
>> +  if [ $ret -eq 0 ] ; then
>> +      # Ignore errors in case some other process has created the same locale.
>> +      # (Some versions of mv do not report an error here.)
>
> How common it these versions?

I do not know.  The behavior is clearly against the documentation.
I don't see an error with coreutils-9.7-9.fc43.x86_64.  I'll report it.
It'll probably be treated as an error in the future.

Florian