> 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...)
> 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""".)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 23 2002 - 22:00:27 EST