Patch, forward release() return values to the close() call
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines
This is a relatively sane part, though I would ask Viro first if changing the prototype of fput is such a great idea. However, the justification below is completely brain damaged.
I would love to hear his opinion,
(I send him this patch some months ago...)
Quoted 3 lines
So, we're here with an error from close. NOW WHAT DO WE DO?! That's right, you have NO CHOICE but to CLOSE AGAIN, and loop until that condition clears (think about
exit()for a moment).
Well waybe I picked with "fail on close" the wrong words, close always succeeds, but yet it's return value can signal error conditions.
$> man close
NOTES
Not checking the return value of close is a common but nevertheless
serious programming error. File system imple
mentations which use techniques as ``write-behind'' to increase
performance may lead to write(2) succeeding,
although the data has not been written yet. The error status may be
reported at a later write operation, but it is
guaranteed to be reported on closing the file. Not checking the
return value when closing the file may lead to
silent loss of data. This can especially be observed with NFS and
disk quotas.
So when closing a file with write-behind cache, close() signals in example an error (it """fails"""), as application I do not have close it again or to circle, but I have to live with the fact that something went wrong, and at least have to inform the user about this, (or return with the error level set, like dd or cp do it, if a close() """fails""".)
Quoted 7 lines
From: Axel Kittenberger <[email protected]>
Date: Fri, 22 Mar 2002 09:06:38 +0100[...]
So when closing a file with write-behind cache,close()signals in example an error (it """fails"""), as application I do not have close it again or to circle, but I have to live with the fact that something went wrong, [...]
I do not think it's true. And what about exit()?
-- Pete