How do you close an ofstream if close() fails?

[jmcdonald]

Good morning,

I ran into an interesting problem recently while coding an application that can write to tape devices, and my searches to date haven't uncovered any solution. I thought that it might be worthwhile to run it by the folks here to see if I'm missing something painfully obvious.

My application is writing data to a tape drive (or in this specific case, a piece of hardware that emulates a tape drive). In handling the exception case where we've filled up the tape drive, I ran into the following...

The ofstream throws an exception when it tries to write and discovers that the tape drive is full... the write fails, the failbit is set, etc. I catch that exception, call ofstream.clear() to reset the fail bit, and then call ofstream.close() inside a try/catch block.

Since this is a tape drive, closing a file results in the writing of an EOF mark to the tape. But apparently, since the tape is full, the EOF mark cannot be written... the close() method throws an exception.

I do subsequently let the ofstream object go out of scope, but it appears that since the close() call failed, the program is keeping an open File Descriptor to the device. While the program is still running, nothing else can open the device... not even the same program. (In fact, I first noticed it because after the failure, I couldn't open a channel to the tape device to rewind the tape.)

So my question is: Is there a way to close the File Descriptor if the close() operation is not working?

I've searched this forum and done some google searches to look for answers, but have found none so far. I've also checked Langer & Kreft's "Standard C++ IOStreams and Locales", but it has nothing on close() failures.

I'd be interested in any constructive feedback anyone can offer. Have I missed something simple and obvious?

Thanks in advance,

John McDonald

[kbw]

That's a tricky one.

The stream class will have attempted to call close on the FD and appears to have failed, so calling it yourself may not be any different. Have you tested this by using the native open/write/close calls?

It could be an omission in the tape driver.

[jmcdonald]

No, I haven't tested it using native calls yet. As soon as I get a chance, I'll write a test driver that does the same with native calls... see if that behaves the same. If so, it sounds like you're correct... it might have to be fixed in the driver.

Thanks for the feedback.

John