Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 22390 - blackdown needs folder /etc/.java/.systemPrefs with at least two files
Summary: blackdown needs folder /etc/.java/.systemPrefs with at least two files
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Lowest normal (vote)
Assignee: Java team
Depends on:
Reported: 2003-06-07 05:11 UTC by Martin Lesser
Modified: 2011-06-14 02:54 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

creates systemPrefs, for blackdown-jdk-*.ebuild/src_install (blackdown.txt,331 bytes, text/plain)
2003-12-24 16:54 UTC, Boris Guskee
modified java-config ebuild to add those files (java-config-1.2.1.ebuild,786 bytes, text/plain)
2004-01-07 12:19 UTC, Christian Gut
fixed typo (java-config-1.2.1.ebuild,792 bytes, text/plain)
2004-01-07 12:21 UTC, Christian Gut
diff for fixed blackdown-jre ebuild (blackdown-jre-1.4.1-r1.diff,584 bytes, patch)
2004-02-17 11:43 UTC, Andrew Sayman
Details | Diff
diff for fixed blackdown-jdk ebuild (blackdown-jdk-1.4.1-r1.diff,566 bytes, patch)
2004-02-17 11:46 UTC, Andrew Sayman
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Lesser 2003-06-07 05:11:35 UTC
When running java-applets as normal user an initial error message is printed:

java.util.prefs.FileSystemPreferences$3 run
WARNING: Could not create system preferences directory. System preferences are unusable.

Every 30 secs an additional error message is printed:

java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock System prefs.Unix error code 4.

strace showed the reason:

16844 stat64("/etc/.java/.systemPrefs", 0xbfffd380) = -1 ENOENT (No such file or directory)
16844 stat64("/etc/.java/.systemPrefs", 0xbfffd350) = -1 ENOENT (No such file or directory)
16844 mkdir("/etc/.java/.systemPrefs", 0777) = -1 ENOENT (No such file or directory)

Reproducible: Always
Steps to Reproduce:
Start i.e. opera from the command line with java/blackdown enabled as normal user. To enable java/blackdown in opera go into Preferences/Multimedia, check the java-box. The path to be entered is /opt/blackdown-jdk-1.4.1/jre/lib/i386/

Solution (to be done as root):

# mkdir -p /etc/.java/.systemPrefs
# touch /etc/.java/.systemPrefs/.systemRootModFile
# touch /etc/.java/.systemPrefs/.system.lock

Actual Results:  
The error messages disappeared

Portage 2.0.48 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4)
System uname: 2.4.20-gentoo-r5 i686 Pentium III (Coppermine)
CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /service /var/lib/svscan /usr/X11R6/lib/X11/xkb"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
USE="x86 oss crypt cups encode gif jpeg kde gnome libg++ mikmod mmx mpeg ncurses nls pdflib png spell truetype xml2 zlib gdbm berkdb slang readline svga X sdl gpm tcpd pam libwww ssl python esd imlib gtk qt motif opengl -3dnow -apm -arts -avi curl doc emacs flash gd imap innodb -java ldap maildir mozilla odbc -oggvorbis perl postgres -quicktime samba scanner tcltk tetex tiff wmf -xmms -xv"
CFLAGS="-mcpu=pentium3 -O3 -pipe"
CXXFLAGS="-O2 -mcpu=i686 -pipe"
FEATURES="sandbox ccache"
Comment 1 Richard Seymour 2003-07-17 11:37:12 UTC
This is also visible in Mozilla under Tools->Web Development->Java Console, as it tries to save the prefs every 30 seconds as well.  Adding those directories (chmoded 755) and those files (chmoded 644) does the trick.  This whole issue has a sun webpage and this: devoted to it.
Comment 2 wolfwood 2003-12-11 17:41:51 UTC
Firstly, are system preferences for a browser plugin actually desirable ?  If so, you can create those directories and files to remove the error and allow saving of applet preferences system-wide, but I would discourage that being done on a universal basis.

Secondly, applet preferences are still saved in ~/.java/.userPrefs/

Thirdly, the problem lies in upstream code, since there is a fallback mechanism that goes from system to user, a SecurityException should not be thrown, nor should that error message be displayed in a Timer, once on initialization is enough.
Comment 3 Adrian Almenar 2003-12-19 21:55:21 UTC
Moving this again to, so everyone out there can help.
Comment 4 Boris Guskee 2003-12-24 16:54:47 UTC
Created attachment 22644 [details]
creates systemPrefs, for blackdown-jdk-*.ebuild/src_install
Comment 5 Boris Guskee 2003-12-24 17:06:46 UTC
The problem is not limited to applets. Move /etc/.java away and run:

class SystemPrefsTest {
    public static void main(String[] args) {

with blackdown-jdk as non-root to see the same warning.

Some rationale from

"The use of system preferences should be rare compared to user preferences. We anticipate that they will be used chiefly to store configuration information (such as what version of a program is installed or what resources it uses). In typical Java platform implementations, ordinary users will not be able to modify system preferences as backing stores typically demand administrative privileges to modify system-wide data."

While it may not be desirable to let applets read system config information, it requires root to make it available. Well, root needs to be careful anyway, doesn't he?

Googling around I found Mandrake (
and SuSE ( do install a basic systemPrefs setup in /etc/.java/. The sun-jdk-1.4.2 ebuilds use $JAVA_HOME/.java which is the second option. I dunno about the other distros.

See the attachment. The program above may serve as a test case.
Comment 6 Christian Gut 2004-01-07 12:19:09 UTC
Created attachment 23335 [details]
modified java-config ebuild to add those files

I think java-config should bring this files, since it is DEPENDed on in every
Comment 7 Christian Gut 2004-01-07 12:21:19 UTC
Created attachment 23336 [details]
fixed typo
Comment 8 wolfwood 2004-01-08 13:34:54 UTC
I would simply refer back to my previous comments here, the _problem_ lies in upstream code, there is little to no reason in most cases for system-wide preferences, and if system-wide preferences cannot be written or read, user preferences are used instead which is preferable in most cases.

I would advise marking UPSTREAM and e-mailing upstream on the affected JRE/JDKs asking why a SecurityException is thrown repeatedly in a timer when there is a fallback mechanism anyways.

But regardless, creating those dirs/files for everyone is not something that should be done without extensive testing since multiple JRE/JDKs may use the same files which might create incompatibilities or inconsistencies.
Comment 9 Andrew Sayman 2004-02-16 21:25:14 UTC
The .systemPrefs directory doesn't need to be in /etc at all. For blackdown-jdk-1.4.1, it needs to be in the /opt/blackdown-jdk-1.4.1/jre directory. For sun-jdk- it seems to need to be in /opt/sun-jdk-
Comment 10 Andrew Sayman 2004-02-17 11:36:42 UTC
I did a little bit more testing with this.

In mozilla-1.6, the error doesn't show up on the console you ran mozilla from anymore. It only shows up in the java console. 

This problem has also been fixed with sun-jdk-, because it now creates the ~/.java/.userPrefs directory instead of relying on the $JAVA_HOME/.systemPrefs that it can't write to.

blackdown-jdk-1.4.1 still requires some sort of .systemPrefs or it will start throwing errors. The simplest way to make it stop is to create an empty .systemPrefs directory in /opt/blackdown-jdk-1.4.1/jre. The directory does not need to contain any files or be writable by the user to stop the error.

Not suprisingly, blackdown-jre-1.4.1 has the same bug which can be fixed in a very similar manner. An empty /opt/blackdown-jre-1.4.1/.systemPrefs is all it takes.
Comment 11 Andrew Sayman 2004-02-17 11:43:38 UTC
Created attachment 25789 [details, diff]
diff for fixed blackdown-jre ebuild

This diff includes the fix for the FileSystemPreferences exception in
blackdown-jre-1.4.1. It just makes the empty directory /opt/${P}/.systemPrefs.
I also removed the keywords and added ~x86, because I've only tested it on x86.
Comment 12 Andrew Sayman 2004-02-17 11:46:27 UTC
Created attachment 25790 [details, diff]
diff for fixed blackdown-jdk ebuild

This patch is very similar to the one above. Because the jre is a subset of the
jdk, I create the directory after the jre directory has been copied.
Comment 13 Andrew Sayman 2004-02-17 12:28:17 UTC
Comment on attachment 25789 [details, diff]
diff for fixed blackdown-jre ebuild

I was wrong, this doesn't fix the bug. This prevents the initial Exception, but
not the one that is thrown every thirty seconds after running an applet.
Comment 14 Andrew Sayman 2004-02-17 12:29:04 UTC
Comment on attachment 25790 [details, diff]
diff for fixed blackdown-jdk ebuild

I was wrong, this doesn't fix the bug. This prevents the initial Exception, but
not the one that is thrown every thirty seconds after running an applet.
Comment 15 Saleem Abdulrasool (RETIRED) gentoo-dev 2005-02-12 15:37:41 UTC
This issue is also valid with Sun's JDK 1.4.2_07.
Comment 16 Christopher Taylor 2006-02-07 17:35:17 UTC
I've run into the same problem here on sun-jdk- (we have /opt mounted ro, so the default behavior doesn't work for us).

I'm not sure about blackdown, but Sun's behavior is *not* creating the .systemPrefs folder if it doesn't exist in the default /etc/.java folder.

The solution _if_ you want the system prefs in /etc is to make a .systemPrefs folder in /etc/.java by hand, _or_ if you want to put it someplace else, define the system preference java.util.prefs.systemRoot to point someplace else as long as that location _also_ has a .systemPrefs folder created by hand, otherwise Sun will override your choice and go back to ${JAVA_HOME}.

This sounds like a Sun bug to me... they could at least try and make the initial directories before giving up IMHO.
Comment 17 Ben Sagal 2011-06-13 19:45:06 UTC
This is an old bug referring to ebuilds that have been removed form the tree, is there a reson for keeping it open?
Comment 18 Serkan Kaba (RETIRED) gentoo-dev 2011-06-14 02:54:08 UTC
(In reply to comment #17)
> This is an old bug referring to ebuilds that have been removed form the tree,
> is there a reson for keeping it open?
Thank you for the reminder.