From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Zack Weinberg <zack@codesourcery.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: close return value (was Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks)
Date: 17 Jul 2002 02:03:02 +0100 [thread overview]
Message-ID: <1026867782.1688.108.camel@irongate.swansea.linux.org.uk> (raw)
In-Reply-To: <20020716232225.GH358@codesourcery.com>
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
next prev parent reply other threads:[~2002-07-16 23:50 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020712162306$aa7d@traf.lcs.mit.edu>
[not found] ` <mit.lcs.mail.linux-kernel/20020712162306$aa7d@traf.lcs.mit.edu>
2002-07-15 15:22 ` [ANNOUNCE] Ext3 vs Reiserfs benchmarks Patrick J. LoPresti
2002-07-15 17:31 ` Chris Mason
2002-07-15 18:33 ` Matthias Andree
[not found] ` <20020715173337$acad@traf.lcs.mit.edu>
[not found] ` <mit.lcs.mail.linux-kernel/20020715173337$acad@traf.lcs.mit.edu>
2002-07-15 19:13 ` Patrick J. LoPresti
2002-07-15 20:55 ` Matthias Andree
2002-07-15 21:23 ` Patrick J. LoPresti
2002-07-15 21:38 ` Thunder from the hill
2002-07-16 12:31 ` Matthias Andree
2002-07-16 15:53 ` Thunder from the hill
2002-07-16 19:26 ` Matthias Andree
2002-07-16 19:38 ` Thunder from the hill
2002-07-16 23:22 ` close return value (was Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks) Zack Weinberg
2002-07-17 1:03 ` Alan Cox [this message]
2002-07-16 23:52 ` close return value David S. Miller
2002-07-17 1:35 ` Alan Cox
2002-07-17 0:20 ` David S. Miller
2002-07-17 1:05 ` Linus Torvalds
2002-07-17 1:05 ` David S. Miller
2002-07-17 1:23 ` Linus Torvalds
2002-07-17 11:51 ` Matthias Andree
2002-07-17 17:23 ` Andries Brouwer
2002-07-20 8:00 ` Florian Weimer
2002-07-20 16:45 ` Linus Torvalds
2002-07-26 0:06 ` EFAULT vs. SIGSEGV [was Re: close return value] Pavel Machek
2002-07-26 14:01 ` (no subject) Alexis Deruelle
[not found] ` <mailman.1026868201.10433.linux-kernel2news@redhat.com>
2002-07-18 0:01 ` close return value Pete Zaitcev
2002-07-18 0:10 ` Thunder from the hill
[not found] ` <mit.lcs.mail.linux-kernel/200207180001.g6I015f02681@devserv.devel.redhat.com>
2002-07-18 14:42 ` Patrick J. LoPresti
2002-07-18 15:13 ` Richard B. Johnson
2002-07-18 15:32 ` Sandy Harris
2002-07-18 23:47 ` Albert D. Cahalan
2002-07-19 16:12 ` Patrick J. LoPresti
2002-07-19 16:24 ` Joseph Malicki
2002-07-19 18:48 ` Patrick J. LoPresti
2002-07-19 19:25 ` Lars Marowsky-Bree
2002-07-19 19:30 ` Arnaldo Carvalho de Melo
2002-07-19 19:45 ` Joseph Malicki
2002-07-19 19:55 ` Arnaldo Carvalho de Melo
2002-07-20 18:25 ` Bernd Eckenfels
2002-07-20 23:06 ` Sandy Harris
2002-07-20 14:42 ` Andries Brouwer
2002-07-18 20:09 ` Hildo.Biersma
2002-07-18 23:55 ` Pete Zaitcev
2002-07-19 11:31 ` Hildo.Biersma
2002-07-19 16:16 ` Pete Zaitcev
2002-07-23 22:19 ` Bill Davidsen
2002-07-17 0:10 ` close return value (was Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks) Zack Weinberg
2002-07-17 1:45 ` Alan Cox
2002-07-17 18:24 ` Zack Weinberg
2002-07-22 16:42 ` Rogier Wolff
2002-07-17 8:00 ` Lars Marowsky-Bree
2002-07-17 15:49 ` Thunder from the hill
2002-07-17 2:22 ` Elladan
2002-07-17 2:54 ` Thunder from the hill
2002-07-17 3:00 ` Elladan
2002-07-17 3:10 ` Thunder from the hill
2002-07-17 3:31 ` Elladan
2002-07-17 4:17 ` Stevie O
2002-07-17 4:38 ` Elladan
2002-07-17 14:39 ` Andreas Schwab
2002-07-17 16:49 ` Elladan
2002-07-17 17:43 ` Linus Torvalds
2002-07-17 22:07 ` Elladan
2002-07-18 9:48 ` Ketil Froyn
2002-07-17 17:17 ` Andries Brouwer
2002-07-17 17:51 ` Richard Gooch
2002-07-17 7:34 ` close return value (was Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks Kai Henningsen
2002-07-15 21:59 ` Ketil Froyn
2002-07-15 23:08 ` Matti Aarnio
2002-07-16 12:33 ` Matthias Andree
2002-07-15 22:55 ` Alan Cox
2002-07-15 21:58 ` Matthias Andree
2002-07-15 21:14 ` Chris Mason
2002-07-15 21:31 ` Patrick J. LoPresti
2002-07-15 22:12 ` Richard A Nelson
2002-07-16 1:02 ` Lawrence Greenfield
[not found] ` <mit.lcs.mail.linux-kernel/200207160102.g6G12BiH022986@lin2.andrew.cmu.edu>
2002-07-16 1:43 ` Patrick J. LoPresti
2002-07-16 1:56 ` Thunder from the hill
2002-07-16 12:47 ` Matthias Andree
2002-07-16 21:09 ` James Antill
2002-07-16 12:35 ` Matthias Andree
2002-07-16 7:07 ` Dax Kelson
[not found] <fa.lfdnrtv.5h8i1j@ifi.uio.no>
[not found] ` <fa.i1e82rv.1digoa4@ifi.uio.no>
2002-07-17 3:46 ` close return value (was Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks) Russ Allbery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1026867782.1688.108.camel@irongate.swansea.linux.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=zack@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).