Re: [bug #46481] install-info can "corrupt" dir file if interrupted.

[Mathieu Lirzin]

Hi,

Gavin Smith <address@hidden> writes:

> On 20 November 2015 at 22:53, Karl Berry <address@hidden> wrote:
>> My $0.00001, fwiw:
>>
>> 1) a signal handler seems crazy to me. That would imply every program
>> that writes anything should catch every signal just because someone
>> might interrupt it.
>>
>> 2) if I type "gcc foo.c" and hit ^C while it's compiling, I do not
>> expect gcc to detect that and keep my previously-existing foo.o.
>> It's not clear to me that there is really a bug here, although it's
>> unfortunate that there are repercussions at the package managers.
>
> At least foo.o is disposable. You can easily recreate it, which
> wouldn't be the case for many other files that could be updated,
> including "dir" by install-info, as the data in it could have come
> from anywhere.

There is a big difference between the behavior expected at compile time
and install time.  You will want every installation operation to be
atomic to garantee the integrity of the system.  As a consequence
avoiding mutation when possible is important (like what seems to be done
for the “dir” file).

>> 3) all that said, writing to a temp file and renaming is at least
>> viable, although rather a pain and susceptible to many hard-to-pin-down
>> bugs
>
> That's my worry too. How do we know that there's not some other way to
> make it fail by abusing the program? What if you turn the power off to
> your computer as the operating system is renaming the file? And so on.

FWIU It is the responsibility of the kernel to garantee the atomicity of
rename(2) or equivalent.

> Because updating a file is such a common task for a program I hoped
> there would be some "best practice" that we could adopt.

I don't know the “best practice” but using a temporary file seems a good
one. ;)


--
Mathieu Lirzin