JDK-4947349 : REGRESSION: RH AS 3.0: prefs.removeNode throws BackingStoreException
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 1.4.0,1.4.1,1.4.2,5.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,linux_redhat_3.0,solaris_8
  • CPU: x86,sparc
  • Submitted: 2003-10-31
  • Updated: 2004-03-31
  • Resolved: 2004-02-20
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.
Other
5.0 b40Fixed
Related Reports
Duplicate :  
Relates :  
Description
Build: Tiger beta b26
Platform: Redhat Advanced Server 3.0 (x86)

Tests:
java_util/prefs/Preferences/SJvm2Thread/userRoot/KeysTest2SJvm2Thread 
and 15 other related tests.

In Redhat Linux AS 3.0, java.util.prefs.BackingStoreException is thrown when Preferences.removeNode() is called. The following piece of code illustrates it.

----------------------------Test.java-----------------------------
import java.util.prefs.*;

public class Test 
{
	public static void main(String[] args)
	{
		Preferences userRoot = null;
		Preferences N1 = null;
		try 
		{
	        userRoot = Preferences.userRoot();
                N1 = userRoot.node("N1");
                N1.clear();
                N1.removeNode();
 
        } catch (Exception e) 
        {
          System.out.println("Exception caught:"+ e.getMessage());
      	}
    }
}

------------------------------------------------------------------------
the following is the output
------------------------------------------------------------------------
Oct 31, 2003 2:37:51 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 22.
Exception caught:Couldn't get file lock.
java.util.prefs.BackingStoreException: Couldn't get file lock.
	at java.util.prefs.FileSystemPreferences.removeNode(FileSystemPreferences.java:657)
	at Test.main(Test.java:29)
------------------------------------------------------------------------

The above code is run on the local system (not on a nfs file system). 

The above problem is not observed with mantis.
 
###@###.### 2003-10-31

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b40 tiger-beta2 VERIFIED IN: tiger-beta2
2004-06-14

PUBLIC COMMENTS Verified by checking the testcase pass in tiger b41 on AS3.0, b43/b44 on AS3.0 AMD. ###@###.### 2004-03-30
2004-03-30

EVALUATION See Suggested fix. Linux native implementation for java.util.prefs includes native file locking code used exclusively by java.util.prefs. As per previous comments this should be removed and should be replaced by file locking code using the facilities provided by the java.nio, java.nio.channels package. A more immediate effective fix is to remove an unnecessary preprocessor directive in the Linux native file locking impl which provides a fragile and incorrect typedef for the file locking params. Should use struct flock64 and never use struct flock for file locking params. java.nio implementation should be provided for 1.5.1 ###@###.### 2004-02-10
2004-02-10

SUGGESTED FIX A previous fix which replaced file locking implementation (migrated from using lockf to using fcntl(fd, F_SETLK64,..) also incorporated a preprocessor directive specific to Linux J2SE compiled native code which was aimed at making file locking work for older 2.2.x based Linux distros. However, the validity of this preprocessor directive (which used 'struct flock' in preference to 'struct flock64' for fcntl file locking operation params and was fragile/sensitive to the Linux build environment (C headers/libs,etc)) does not hold across all Linux 2.4.x supported distros. Since 2.2.x distros are no longer officially supported for 1.5.0 an immediate effective fix is to remove the preprocessor directive and ###@###.### 2004-02-10
2004-02-10