[BusyBox] Re: ifconfig: Clean up. [PATCH]

Bernd Petrovitsch bernd at firmix.at
Wed Jul 27 12:10:59 UTC 2005


On Wed, 2005-07-27 at 11:29 +0200, Rainer Weikusat wrote:
> Bernd Petrovitsch <bernd at firmix.at> writes:
> 
> > On Wed, 2005-07-27 at 10:03 +1000, Glenn L. McGrath wrote:
> > [...]
> >> We should be closing and checking the return value of close. I was going
> >> to jump on this problem at one time for the archiving code, but i never
> >> got around to it.
> >> 
> >> >From man close(2)
> >> 
> >> "Not checking the return value of close is  a  common  but  nevertheless
> >> serious  programming error.  It is quite possible that errors on a
> >> previous write(2) operation are first reported at the  final  close.  
> >> Not checking the return value when closing the file may lead to silent
> >> loss of data.  This can especially be observed with NFS and with disk
> >> quota."
> >
> > The foolowing patch wasn't accepted, though
> > http://www.cs.helsinki.fi/linux/linux-kernel/2002-11/0955.html
> >
> > And AFAIK this hasn't changed afterwards in the Linux kernel.
> >
> > The issue was also mentioned on
> > http://lwn.net/2002/0328/kernel.php3.
> 
> Quoting from there:
> 
> 	Not everybody agrees that this is the right thing to do,
> 	interestingly. It has been stated that the fsync() call should
> 	be used by applications which are interested in any
> 	last-minute errors.
> 
> And this is The Right Thing[tm] because the kernel does write-back
> caching of data that is written out to disk files in any case, which
> means that without fsync(2), the data may later be lost, no matter
> what close(2) had returned.

Given that I interpret your answer correctly, the man page of close(2)
is wrong and error checking on close(2) is absolutely pointless.
Actually the function prototype should be changed to "void
close(void);".

This seems to resemble the current impülementation in the Linux kernel.
Is this different on other kernels?

Apart from avoiding the confusion (which will surely come) in the above
mentioned thread, why the fd is destroyed even if close(2) failed
before.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




More information about the busybox mailing list