FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)


FULL OPERATING SYSTEM VERSION :
SunOS pantar 5.7 Generic_106541-17 sun4u sparc SUNW,Ultra-4

EXTRA RELEVANT SYSTEM CONFIGURATION :
System has 4 CPUs.

A DESCRIPTION OF THE PROBLEM :
The length() method of java.io.RandomAccessFile temporarily
changes the file pointer.  If it is called in one thread,
another thread that does a read() or write() can do so at
the wrong offset.  Conversely, a seek() in another thread
can be lost due to a simultaneous call to length().

This should either be clearly documented in the API
specification (requiring users to synchronize calls to
length() with those to other file methods) or fixed using
some kind of internal lock.


REPRODUCIBILITY :
This bug can be reproduced occasionally.

CUSTOMER WORKAROUND :
synchronize all calls to relevant methods on some  customer ,
e.g. the RandomAccessFile instance itself.
(Review ID: 181612) 
======================================================================
Posted Date : 2005-11-16 08:17:09.0

N/A

The implementation of RandomAccessFile.length() does three seeks: 
 
  1.  seek to save the current file position 
  2.  seek to the end to obtain the offset of the end of the file (the  
      returned length) 
  3.  seek to the saved file position to reset the original file 
      pointer position 
 
Naturally, in a multithreaded scenario, this could cause problems if other seek operations are occuring in other threads.  Locking all operations on RandomAccessFile would cause performance problems so it would be more desirable to find native APIs that can retrieve this length atomoically.   
 
A possible candiate for unix is the st_size field in the stat structure returned by fstat.  Potential problems may be that this value does not properly handle sparse files on all systems or the data type of st_size does not correctly support files of length > 4G. 
 
For windows, GetFileSize will return the total size including the sparse regions, which is what the current implementation effectively does.
Posted Date : 2005-11-16 08:17:10.0

I agree with the above analysis.  
length() can be made more thread-safe, without performance penalty,
on at least some operating systems.
This is a defect, not an rfe.
Posted Date : 2006-02-12 21:12:16.0

Why doesn't the implementation use fstat() to find the
length instead of three seeks?

Why has every occurrence of "other" in the description been replaced by "xxxxx" ?

I had a bug in my multithreaded code and it took me FOREVER to realize it was the unsynchronized call to length().  Please mention this in the documentation for the seek() method as well as the length() method.
Thanks.

I have experienced the same problem in JDK6 . Could you please fix it or mention it in documentation.
Thanks

As said before, ¿could the synchronization details be added to the documentation? 
Thanks