Re: [PATCH sed] ck_fclose should unlink *before* calling do_ck_fclose.

Eric Blake <[email protected]>
Newsgroups gmane.comp.gnu.utils.bugs
Organization Red Hat, Inc.
Message-ID <[email protected]>
On 06/03/2014 02:55 PM, Stanislav Brabec wrote:
> NeilBrown wrote:
>> If do_ck_fclose gets an error from fclose() it will call
>> panic() which will try to close everything on the list.
> 
> There is a question: Why this code is needed at all? Is there a
> platform, where exit(4) later in panic() keeps open file descriptors?

exit() is guaranteed to close fds, but NOT guaranteed to affect return
status if there was an error detected during the close.  We'd rather
close things manually, so that we can force a non-zero exit status via
_exit() if the close failed (which, for some filesystems such as NFS, is
all too real of a possibility).


> And even: Why the fflush() is called before fclose()? fclose() should
> always flush. Isn't the error of fclose() sufficient? (Especially if
> both end in panic().)

Again, fclose() is guaranteed to attempt a flush, but not guaranteed to
do sane reporting of errors in that process.  Doing a manual fflush()
first gives us better error reporting.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc (application/pgp-signature, 604 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJTjkEmAAoJEKeha0olJ0NqKswH/2KhtUkKMM/Mwvr+fof8f5We
TBd3EVCMQTR2xDAzq12byf7qH0XpDrkMTziJwgd2DvfZV3yoVHv/504Hu7zTKp20
LAzQcKJpIN4mDdpEyE+iexBseqJGhnjF7XzihGTqxiqw9uGMGMActlk5LYfLoqmT
f4unMGCW23vL60Tee9MHTMk4lK2T/e72tA0YZdTt7P71IJTpAO1dUoHAQtN9/GKX
dpY6iERmb8QtJDaDlBWNlzmA71LKYsdw8sgXV6ULWk1dFlsuZ3CSzUwH3bT77TAK
cVpTbODPRKGgYfl77JT8mWNRHLD3b8OKdonlXidkZuMRpBToOKcmaKV+A3/V7NU=
=5nBJ
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.