JDK-4823133 : RandomAccessFile.length() is not thread-safe
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.4.1,5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_7,windows_xp
  • CPU: x86,sparc
  • Submitted: 2003-02-24
  • Updated: 2019-03-11
  • Resolved: 2016-01-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b101Fixed
Related Reports
Duplicate :  
Relates :  
Description
Name: nt126004			Date: 02/24/2003


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 object,
e.g. the RandomAccessFile instance itself.
(Review ID: 181612) 
======================================================================

Comments
EVALUATION 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.
12-02-2006

EVALUATION 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.
16-11-2005