[lkml]   [2002]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: close return value (was Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks)
    On Wed, 2002-07-17 at 00:22, Zack Weinberg wrote:
    > Making use of the close return value is also never any good.

    This is untrue

    > 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.

    close() checking is not about physical disk guarantees. It's about more
    basic "I/O completed". In some future Linux only close() might tell you
    about some kinds of I/O error. The fact it doesn't do it now is no
    excuse for sloppy programming

    > 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.]

    If it bothers you close it again 8)

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

    The man page matches the stsndard. Implementation may be a subset of the
    allowed standard right now, but don't program to implementation
    assumptions, it leads to nasty accidents

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:27    [W:0.026 / U:47.436 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site