FileHandle: don't unnecessarily init a RandomAccessFile on close

[gab1one]

If we close a handle on a file that does not exist, we do not need to
initialize the RandomAccessFile, just to close it again. This fixes the problem of
empty files appearing when closing a FileHandle to a file that does not exist.

[ctrueden]

Unfortunately, this simple fix can result in a race condition if close() is called near-simultaneously with another thread that causes the RandomAccessFile to be initialized.

Suppose Thread1 calls fileHandle.writeShort(555); and Thread2 then calls fileHandle.close() while Thread1's operation is in the middle of the new RandomAccessFile call. The raf reference has not yet been assigned, so Thread2's close operation will do nothing.

Maybe this doesn't matter, because RandomAccessFile is not thread-safe anyway. So fileHandle really should not be shared between Thread1 and Thread2.

If we do care for some reason, the only easy fix I can see is to add a new method like getRAF() which is synchronized, and returns raf. This would minimize the chances of (but not fully prevent!) close() doing nothing while another thread is in the midst of the initRAF() operation.

What do you think?

[gab1one]

I don't think a single handle should be shared between threads at all, as this can very easily result in data corruption unless the threads are coordinating their access somehow.

[gab1one]

@ctrueden with the added synchronized access do you mean something like I did in commit fdfc4ef ?
That should protect us from the scenario with the closing of a FileHandle that is just initializing.

[ctrueden]

@gab1one Let's just make the close() method synchronized. Simpler, less buggy, no less efficient. No?