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

[Pedrum Mohageri]

Resending. I forgot to reply-all.

On Fri, Nov 20, 2015 at 3:19 AM, Gavin Smith <address@hidden> wrote:

On 19 November 2015 at 21:48, Pedrum Mohageri <address@hidden> wrote:

> Details:
>
> I use Arch and the package manager bailed out on several packages during the
> install. I traced this to a failed install-info call to add entries for
> package to the 'dir' that info use.
>
> After strace'ng the code, I observe it will do a open with O_TRUNC flag, and
> then write out some data. If the process is killed between the open and write,
> it will leave 0 byte dir file which can't written to by subsequent
> install-info calls. You should consider replacing this with a 'write to
> temp/rename temp to dir' changeover that's atomic.

I think this "open" is done when "fopen" is called.

Can you point to an explanation or example of how to update a file
without the risk of truncation? It would seem that there's the risk of
this happening any time that fopen (... , "w") is used; should that be
considered a bad way to update a file.

You can use the standard practice of 1) writing to temp file 2) renaming temp file to final file. This ensures the file contents are fully on disk before the name change occurs.

See also: http://www.gnu.org/software/libc/manual/html_node/Temporary-Files.html.  

There are various libc ways to get a tempfile securely, and then use a rename/linkat calls to rename to filename you're replacing.

 

> While this is rare occurrence, I've seen numerous failures like this reported
> on Redhat and Arch forums.

Can you email links to these reports?

https://bugzilla.redhat.com/show_bug.cgi?id=581995

https://bbs.archlinux.org/viewtopic.php?pid=673587 

 

Why was install-info killed anyway? If it was due to C-c being typed
on the controlling terminal, could we maybe catch and ignore the
signal to make sure we finish?

I suspect it was a control-c from command line (at least for me). Once it gets corrupted (meaning a truncated file), it'll stay like that until a user either removes the dir file and recreates the index.

Signal handlers are tricky and have certain limitations (see below link). I guess a quick fix could be to look for a zero byte dir file and remove it, but I'd suggest fixing how the actual writes are being done.

https://www.gnu.org/software/libc/manual/html_node/Nonreentrancy.html