Re: Segmentation fault in dcigettext.c:925 using Apache + PHP

[Wiebe Cazemier]

----- Original Message -----
> From: "Bruno Haible" <bruno@clisp.org>
> To: "Wiebe Cazemier" <wiebe@halfgaar.net>
> Cc: bug-gettext@gnu.org
> Sent: Wednesday, 24 June, 2020 23:20:38
> Subject: Re: Segmentation fault in dcigettext.c:925 using Apache + PHP
>
> It will not crash - and the process will continue to use the old .mo file -
> if you do it in such a way that the inodes are different. So:
> 
>  cp new.mo $LOCALEDIR/$locale/LC_MESSAGES/domain.mo    => crash
> 
>  cp new.mo $LOCALEDIR/$locale/LC_MESSAGES/domain.mo.new \
>  && mv $LOCALEDIR/$locale/LC_MESSAGES/domain.mo.new
>  $LOCALEDIR/$locale/LC_MESSAGES/domain.mo
>  => works
> 
>  ln $LOCALEDIR/$locale/LC_MESSAGES/domain.mo
>  $LOCALEDIR/$locale/LC_MESSAGES/domain.mo.old \
>  && cp new.mo $LOCALEDIR/$locale/LC_MESSAGES/domain.mo.new \
>  && ln -sf domain.mo.new $LOCALEDIR/$locale/LC_MESSAGES/domain.mo
>  => works
> 
> It's like this for every file that is mapped. The kernel implements a write-
> protection (cp would fail with ETXTBUSY) for some such files, namely swap 
> files,
> executables and shared libraries, but not for anything else.
> 
> Bruno

Yeah, we already implemented out-of-place updating of the mo file.

I was (quietly) also wondering if msgfmt would do better creating a new file 
instead of truncating the existing one. But, looking at search results, we are 
the only ones who have this problem, so probably creating .mo files frequently, 
based on user interaction, is a uncommon use case.