Name: nt126004 Date: 10/14/2002
FULL PRODUCT VERSION :
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)
and
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)
FULL OPERATING SYSTEM VERSION :
Linux 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown
A DESCRIPTION OF THE PROBLEM :
On linux,
I think the preferences file(s) are in /etc/.java, and I have deleted
this directory several
times, anticipating something like what was mentioned in the blurb of
4404011; and presuming the
application re-creates the files it needs here. I've also chmod'ed
things so all users can write to /etc/.java, so I
don't think its a permissions thing. But I still get the same errors. I
think it's something to do
with my home area being on nfs, and whether the flock() commands work
across nfs etc (as implemented
in the relevant java classes...)
For example.............
ls /etc/.java/.systemPrefs/ -al
total 8
drwxrwxrwx 2 GUN057 dpr 4096 Sep 30 11:29 ./
drwxrwxrwx 3 root root 4096 Sep 30 11:29 ../
-rw-rw-rw- 1 GUN057 dpr 0 Sep 30 11:29 .system.lock
-rw-rw-rw- 1 GUN057 dpr 0 Sep 30 11:31 .systemRootModFile
and I'm still getting....
horatio:Test% Oct 8, 2002 10:01:17 AM
java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 37.
Oct 8, 2002 10:01:17 AM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs:
java.util.prefs.BackingStoreException: Couldn't get file lock.
experiments confirm that if ~/.java is deleted, the error persists. However, if I make it a symm
link to somewhere on a local drive, the error disappears, so it's definitely nfs related. The symm link hack is
unsatisfactory of course, but its an idea I saw somewhere. The bug also cripples the application after a few
minutes, as it runs out of file descriptors or something.
I think maybe its bug 4673298. Still unsolved?
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.See Bug 4398496 (duped to 4404011)
REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 165141)
======================================================================
###@###.### 11/3/04 20:36 GMT
FULL PRODUCT VERSION :
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)
and
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)
FULL OPERATING SYSTEM VERSION :
Linux 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown
A DESCRIPTION OF THE PROBLEM :
On linux,
I think the preferences file(s) are in /etc/.java, and I have deleted
this directory several
times, anticipating something like what was mentioned in the blurb of
4404011; and presuming the
application re-creates the files it needs here. I've also chmod'ed
things so all users can write to /etc/.java, so I
don't think its a permissions thing. But I still get the same errors. I
think it's something to do
with my home area being on nfs, and whether the flock() commands work
across nfs etc (as implemented
in the relevant java classes...)
For example.............
ls /etc/.java/.systemPrefs/ -al
total 8
drwxrwxrwx 2 GUN057 dpr 4096 Sep 30 11:29 ./
drwxrwxrwx 3 root root 4096 Sep 30 11:29 ../
-rw-rw-rw- 1 GUN057 dpr 0 Sep 30 11:29 .system.lock
-rw-rw-rw- 1 GUN057 dpr 0 Sep 30 11:31 .systemRootModFile
and I'm still getting....
horatio:Test% Oct 8, 2002 10:01:17 AM
java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 37.
Oct 8, 2002 10:01:17 AM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs:
java.util.prefs.BackingStoreException: Couldn't get file lock.
experiments confirm that if ~/.java is deleted, the error persists. However, if I make it a symm
link to somewhere on a local drive, the error disappears, so it's definitely nfs related. The symm link hack is
unsatisfactory of course, but its an idea I saw somewhere. The bug also cripples the application after a few
minutes, as it runs out of file descriptors or something.
I think maybe its bug 4673298. Still unsolved?
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.See Bug 4398496 (duped to 4404011)
REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 165141)
======================================================================
###@###.### 11/3/04 20:36 GMT
- relates to
-
JDK-4947349 REGRESSION: RH AS 3.0: prefs.removeNode throws BackingStoreException
-
- Closed
-