This is the mail archive of the
mailing list for the binutils project.
Re: [Bug-readline] [PATCH] readline/histfile.c: Check and retry write() operation in history_truncate_file()
- From: Chen Gang <gang dot chen dot 5i5j at gmail dot com>
- To: chet dot ramey at case dot edu
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, palves at redhat dot com, gdb-patches at sourceware dot org, binutils at sourceware dot org, bug-readline at gnu dot org, amodra at gmail dot com
- Date: Sat, 21 Jun 2014 10:25:31 +0800
- Subject: Re: [Bug-readline] [PATCH] readline/histfile.c: Check and retry write() operation in history_truncate_file()
- Authentication-results: sourceware.org; auth=none
- References: <5397C077 dot 1080702 at gmail dot com> <53A1F78A dot 8020508 at case dot edu> <53A23D77 dot 1040905 at gmail dot com> <53A3F78E dot 6020803 at gmail dot com> <53A4AD62 dot 6020408 at case dot edu>
On 06/21/2014 05:53 AM, Chet Ramey wrote:
> On 6/20/14, 4:57 AM, Chen Gang wrote:
>> On 06/19/2014 09:31 AM, Chen Gang wrote:
>>> On 06/19/2014 04:33 AM, Chet Ramey wrote:
>>>> On 6/10/14, 10:35 PM, Chen Gang wrote:
>>>>> For regular file, write() operation may also fail, so check it too. If
>>>>> write() return 0, can simply wait and try again, it should not suspend
>>>>> infinitely if environments have no critical issues.
>>>> Readline-6.3 checks the return value from write() and returns a non-zero
>>>> value to the history_truncate_file caller. I really don't think that
>>>> waiting forever if write continues to return 0 is a great idea; an error
>>>> return is enough to let the caller deal with it.
>> Oh, sorry, after think of again, for me, we have to waiting forever if
>> write() continues to return 0.
> There aren't really any plausible conditions under which write(2) returns
> 0 instead of -1 when writing a non-zero number of bytes to a regular file.
Hmm... for me, what you said is acceptable. And the function comment need be
"Returns 0 on success, errno or -1 on failure"
>> When this case happens, the file is already truncated, and the left data
>> which is writing to file will be free after return from
>> If return an error code in this case, the caller can not deal with it --
>> the log data which should be remained, have been lost, can not get them
>> back again.
> However, you're right about the data being lost if write fails and returns
> -1. Since the sequence of operations is open-read-close-open-write-close, I
> think I will change the code for the next version to use a scheme similar
> to history_do_write() and restore the original version of the file if the
> write fails.
And since you will work for it next, is it still necessary to send patch v2 for
the temporary fix, at present?
Open share and attitude like air warter and life which God blessed