What's the practical use of the error close() returns?

What's the practical use of the error close() returns?

Orna Agmon Ben-Yehuda ladypine at gmail.com
Fri Jul 27 17:08:49 IDT 2012


On Fri, Jul 27, 2012 at 2:52 PM, Elazar Leibovich <elazarl at gmail.com> wrote:

> Thanks!
>
> You nailed it! closing a file twice is an error that makes sense to be
> issued at close. So simple, how could I miss it?
>
> (as mentioned earlier, the "no space left" could just as well happen after
> the file was closed, so I don't mind that much it's not reported on a
> close())
>

It can, happen later, true. But if you know that it happened at close time
you can take measures. For example, If I get this, I issue a pop-up message
with the error message without trying to write the error to the log. This
way I have a better chance to reach the user with the information of what
went wrong.

>
>
> On Fri, Jul 27, 2012 at 12:29 PM, Orna Agmon Ben-Yehuda <
> ladypine at gmail.com> wrote:
>
>> My practical answer:
>>
>> I always check fclose() . It happened to me that it returned errors when
>> the file I was trying to close was already closed (which usually meant  I
>> had a bug, because I closed one file  twice, another never. It also failed
>> with "no space left on device", when it was trying to flush the rest of the
>> data that was on the way to the file.
>>
>> Orna
>>
>>
>> On Thu, Jul 26, 2012 at 11:49 PM, Elazar Leibovich <elazarl at gmail.com>wrote:
>>
>>> I was always intrigued by this unix tidbit, closing a file can return an
>>> error. In practice, it is rarely checked (as far as I've seen)
>>>
>>> What does it mean? If I understand it correctly, recent write can lie
>>> about its success.
>>>
>>> But when do you really need it? If you have a piece of information you
>>> want to make sure it hits the disk, the reasonable thing to do is to fsync
>>> the file, and check the error of the fsync. If you don't care about it that
>>> much, then don't check the error, you don't have much to do even if it
>>> failed. It seems to me that one can make close return void, and point the
>>> one who wishes to make sure data hit the disk to fsync.
>>>
>>> What's the practical use case, where you care about close() error, but
>>> you don't care enough to need an fsync.
>>>
>>> Another question is, why let write lie about its success, what does it
>>> gain you? Let close return void, and force write never to defer its error
>>> reporting.
>>>
>>> _______________________________________________
>>> Linux-il mailing list
>>> Linux-il at cs.huji.ac.il
>>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>>
>>>
>>
>>
>> --
>> Orna Agmon Ben-Yehuda.
>> http://ladypine.org
>>
>
>


-- 
Orna Agmon Ben-Yehuda.
http://ladypine.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20120727/622edee8/attachment.html>


More information about the Linux-il mailing list