On Fri, Jul 27, 2012 at 2:52 PM, Elazar Leibovich <[email protected]> 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 < > [email protected]> 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 <[email protected]>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 >>> [email protected] >>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il >>> >>> >> >> >> -- >> Orna Agmon Ben-Yehuda. >> http://ladypine.org >> > > -- Orna Agmon Ben-Yehuda. http://ladypine.org
_______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
