lkml.org 
[lkml]   [2002]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    Subjectclose return value (was Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks)
    From
    Thunder wrote:
    > On Tue, 16 Jul 2002, Matthias Andree wrote:
    > > Indeed, but OTOH, what error is close to report when the file is
    > > opened read-only?
    >
    > Well, you can still get EIO, EINTR, EBADF. Whatever you say,
    > disregarding the close return code is never any good.

    Making use of the close return value is also never any good.

    Consider: There is no guarantee that close will detect errors. Only
    NFS and Coda implement f_op->flush methods. For files on all other
    file systems, sys_close will always return success (assuming the file
    descriptor was open in the first place); the data may still be sitting
    in the page cache. If you need the data pushed to the physical disk,
    you have to call fsync.

    Consider: If you have called fsync, and it returned successfully, an
    immediate call to close is guaranteed to return successfully. (Any
    hypothetical f_op->flush method would have nothing to do; if not, that
    filesystem does not correctly implement fsync.)

    Therefore, I would argue that it is wrong for any application ever to
    inspect close's return value. Either the program does not need data
    integrity guarantees, or it should be using fsync and paying attention
    to that instead.

    There's also an ugly semantic bind if you make close detect errors.
    If close returns an error other than EBADF, has that file descriptor
    been closed? The standards do not specify. If it has not been
    closed, you have a descriptor leak. But if it has been closed, it is
    too late to recover from the error. [As far as I know, Unix
    implementations generally do close the descriptor.]

    The manpage that was quoted earlier in this thread is incorrect in
    claiming that errors will be detected by close; it should be fixed.

    zw
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:22    [W:2.481 / U:0.224 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site