Exception during a file close() can be ignored (traced only), resulting in spurious follow on errors
Activity

Gavin Halliday November 20, 2020 at 11:43 AM
Most likely for this to be addressed when the disk reading is switch over to using a refactored interface, since everything will need to be looked at then.

Richard Chapman May 29, 2020 at 5:03 PM
I think relying on the destructor to flush is a flawed design, and we will need (at some point) to fix it...

Jacob Cobbett-Smith May 29, 2020 at 4:34 PM
- hesitant about taking this approach, mainly because of the number of changes it probably implies..
Any pragmatic alternatives?

Jacob Cobbett-Smith May 29, 2020 at 4:33 PM
I'm not sure how we should best handle it.
From IM discussion:
Jake: The problem is that there's the IFileIO is deeply contained in streams etc. and when it's released, hits the I/O exception
it's then too late to pass on.. and CFIleIO can only log it.
Potentially the interfaces could expose a 'close' or 'finalize' so it could call through to wind things up,
and callers to ensure they call before releasing...
but that would be a pain to implement everywhere/catch all places
Gavin: I suspect the only safe solution is adding a flush/close call.
Jake: it gets messy, e.g. in this particular case, one of the methods in the chain is this:
Jake: so there's need to be a 'finalize' method in IRowWriter, so the caller could ensure it is finalized before released
It then would have to call through to others that actually contain the IFileIO, i.e. in this case a IFileIOStream
so that too would need to have a 'finalize' method ..
Jake: And this is just 1 case, there may be many other paths, where implementations contain IFileIO and rely on flush() and release semantics only

Jacob Cobbett-Smith May 29, 2020 at 4:31 PM
Stack / log of incident seen:
Details
Components
Assignee
Available for anyoneAvailable for anyoneReporter
Jacob Cobbett-SmithJacob Cobbett-SmithPriority
MajorCompatibility
Minor
Details
Details
Components
Assignee

Reporter

This issue has been seen in a cloud setup.
It resulted in a "assert(required <= maxAvailable())" error being reported, instead of the real Disk Full issue (see ).
This happened because close() is called in the CFileIO dtor.
It deliberately catches, traces and disposed of any exception it hits, to avoid causing an abort if the exception were to be rethrown in the dtor.