🚀 go-pugleaf

Having in mind that RandomAccessFile (RAF) in fact does some file 
locking on the Win32 native packages, I walked from the simple question: 
"What can channel file-locking do for me what RAF doesn't already do for 
me?". After all it takes some extra time and resources to install code 
for channel file-locking.

Some initial experiments in VM 1.4.2_06 have shown a somewhat funny picture.

Exp A. Open a file in RAF and then try open it in external process (here 
MS-Word and Notepad)
- Notepad (demanding only read-access) can retrieve the file's text
- Word (demanding read/write-access) is broken with the correct message 
like "file in use by other process")

Exp. B. Open a file in RAF, add a channel lock with "tryLock()" and then 
try open it in external process (here MS-Word and Notepad)
- Notepad cannot retrieve the file's text (silent)
- Word is broken with a confusing message, like "file not found etc. ..."

Exp. C. Open a file in MS-Word (read/write-access) and then try open it 
in RAF
- RAF is broken with "file not found" exception and the correct message 
like "file in use by other process".

My first, provisorical conclusions from the above are:

1)  both approaches (classic IO and channels) are performing some kind 
of file locking on the native file access layer
2)  classic IO packages and channel locking are using different native 
resources or manipulations to acquire a file lock
3)  RAF locks seem to allow other processes to discriminate between read 
and write access while channel locks seem to always block both.
4)  If you want to block away ANY secondary access (including read 
access) you have to use channel locks
5)  Channel locks may result in misleading error messages