NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 187 - error saving/loading preferences
error saving/loading preferences
Status: RESOLVED FIXED
Product: Fiji
Classification: Unclassified
Component: Plugins
unspecified
PC Windows
: P4 normal
Assigned To: ImageJ Bugs Mailing List
Depends on:
Blocks:
 
Reported: 2010-06-18 12:49 CDT by Christian
Modified: 2010-08-31 14:09 CDT
1 user (show)

See Also:

Description Christian 2010-06-18 12:49:49 CDT
Hi
With one of the last updates came one new problem when starting or quitting fiji.
The program seeks to save or load preferences in  a path that is not accessible. The error message reads: \\fileserver\profiles$\Desktop\IJ_Prefs.txt (Zugriff verweigert)
I work in a network environment that allows us to work from any machine within the institute. Thus the reference to \\fileserver. Where fiji gets this path from i don't know. I'd much rather have it try to save my preferences somwhere related to the path where it resides, which is local c: drive.
Can this be improved? Is there a way to set it to use a different path?

Information about your version of Java - this information is useful for the Fiji developers:
  os.arch => x86
  os.name => Windows XP
  os.version => 5.1
  java.version => 1.6.0_16
  java.vendor => Sun Microsystems Inc.
  java.runtime.name => Java(TM) SE Runtime Environment
  java.runtime.version => 1.6.0_16-b01
  java.vm.name => Java HotSpot(TM) Client VM
  java.vm.version => 14.2-b01
  java.vm.vendor => Sun Microsystems Inc.
  java.vm.info => mixed mode
  java.awt.graphicsenv => sun.awt.Win32GraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.6
  sun.cpu.endian => little
  sun.desktop => windows
  file.separator => \
Comment 1 Johannes Schindelin 2010-06-18 15:30:10 CDT
Unfortunately, the change was due to an explicit user request (see http://pacific.mpi-cbg.de/cgi-bin/bugzilla/﷒0﷓, in general, it is a good idea to search the bugzilla for keywords related to your problem). The preferences should be user-specific.

So changing it back to an application-specific place would break that again. You might understand that this is not in our mutual interest.
Comment 2 Christian 2010-07-05 16:47:14 CDT
(In reply to comment #1)
> Unfortunately, the change was due to an explicit user request (see
> http://pacific.mpi-cbg.de/cgi-bin/bugzilla/﷒0﷓, in general, it
> is a good idea to search the bugzilla for keywords related to your problem).
> The preferences should be user-specific.
> 
> So changing it back to an application-specific place would break that again.
> You might understand that this is not in our mutual interest.
> 
I apologize for not having found that and for not being clear enough. But there still is an issue. First: i am fine with having the preferences in a user-specific place of course. But it seems that in the case of the network environment at the institute here, FIJI confuses the path and attempts to search or write the preferences in a directory the user has no access to.
I haven't found the reason for that when reading the patch you attached (...show_bug.cgi?id=184), neither did our admin.
I want to describe two scenarios and the outcome that might give a clue to the problem.
One: I log onto the machine locally (without all the roaming functionality of our network environment)Outcome: FIJI uses "C:\Dokumente und Einstellungen\<username>\ as preference directory and encounters no problem.
Two: I log onto the network environment. Outcome: ImageJA uses \\fileserver\profiles$\Desktop\ and fails to read/write.
Now, \\fileserver\profiles$\Desktop\ is not a path that ImageJA would get from the system, at least it doesn't exist in the registry variables. It is rather a path that is a truncated part of a path that exists there, which would be \\fileserver\profiles$\Desktop\<username>\ if ImageJA were to use that path it would save the preferences in a funny, but user-specific place (on the users desktop). Is there any place in the code, where such a truncation stopping at "Desktop" would happen?
Comment 3 Johannes Schindelin 2010-07-06 10:31:08 CDT
The path Fiji tries to access is determined by the "user.home" property. From http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#getProperties() I assumed that "user.home" is the "User's home directory".
Comment 4 Christian 2010-07-19 17:14:06 CDT
Hi Johannes. After spending some more time with our admin and searching the web I have found this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4787931 .
Well, I see that it's nothing to do with FIJI. It is just that system.get.property(user.home) returns nonsense on some windows systems. I confirmed that this is the problem I'm having by testing the command in an independent java project on my machine. There seem to be a couple of (awkward)workarounds. Can you see anything that could be used in FIJI without breaching useability in other os?
Comment 5 Johannes Schindelin 2010-08-29 19:17:28 CDT
You could use some getenv() call guarded by a check whether we're on Windows.

But note that there is an ongoing controversy whether USERPROFILE is the place to put things or HOMEDRIVE/HOMEPATH is it. It would not do any good to please just one half of the users, while offending the other one.
Comment 6 Christian 2010-08-30 11:16:23 CDT
Well, I really don't care where it puts things as long as it picks a place where it has access. As pointed out in javas bugdatabase http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4787931
it is an ongoing issue with windows users who have their user profiles on some remote server that their java programs try to go to places where they can't write. It affects all java programs that try to put anything in a user related place.
The reason is the bug in the command "system.get.property(user.home)" which returns non functional paths. If I were more proficient in programming I would try one of the fixes mentioned in above thread in bugs.sun.com. My problem is that, being merely a basic user, I don't know how to implement such a fix in my fiji. 
Comment 7 Stephan Saalfeld 2010-08-30 11:41:22 CDT
Johannes---may be that is a stupid idea but what about the following solution?

We introduce an optional environment variable $FIJI_USERHOME which is expected to contain the path a user wants to save his/her settings.  That is checked first when attempting to get the path for saving settings.  If it doesn't exist or doesn't allow opening a file, the current behavior is called.

In that scenario, Christian's admin could setup this system variable for each user and Fiji would work fine and save in a reasonable place.  It's a bit like with the JAVA_HOME thing.

What do you think?  If you could point me to the place where the settings are saved, I could help implementing it---doesn't sound like much effort.
Comment 8 Johannes Schindelin 2010-08-30 12:03:32 CDT
Stephan, a very good idea!

The prefsDir is set here:

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=ImageJA.git;a=blob;f=ij/Prefs.java;h=4f812755b4f47698bb959acaa6ce1577edf2167e;hb=c08cf5bd42734df6ad8e557117cd366009e561cc#l144

But as you can see, it tries to use homeDir, which can be set by ImageJ's -ijpath option:

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=ImageJA.git;a=blob;f=ij/ImageJ.java;h=4959abfa3bd35829d51608433e7797273a28ecc9;hb=c08cf5bd42734df6ad8e557117cd366009e561cc#l580

So there are two options: either we patch the Fiji launcher (which would mean that we need to recompile all the launchers), or we put the stuff into fiji.Main:

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=fiji.git;a=blob;f=src-plugins/Fiji/fiji/Main.java;h=c79a55613335b2984fe1a2aa41dd8cc8b16a94d3;hb=1cb83ff476115d7f80b336d3c0f00f3a5dfa1b6d#l358

Something like

    String fijiPrefsDir = System.getenv("FIJI_PREFS_DIR");
    if (fijiPrefsDir != null) {
         String[] args2 = new String[args.length + 2];
         args2[0] = "-ijpath";
         args2[1] = fijiPrefsDir;
         System.arraycopy(args, 0, args2, 2, args.length);
         args = args2;
    }

should do the trick, but I haven't checked that all the code paths leading up to Prefs.loadPrefs() parse the -ijpath parameter properly. I'd just try that out, though.
Comment 9 Stephan Saalfeld 2010-08-30 13:01:31 CDT
Johannes,

thanks for the reply.  That is, the workaround for Christian's trouble would be to launch Fiji with -ijpath MY:\home\path until we include the setenv checking?

I propose the following hierarchy for choosing that path:

1. -ijpath
2. IJ_HOME
3. user.home
4. ...

Not as deeply involved in the ImageJ logic, can you give me a hint how

Prefs.prefsDir and Prefs.homeDir are expected to be related to each other?

In ij.Prefs, I can see both as static fields with only homeDir published through a setter

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=ImageJA.git;a=blob;f=ij/Prefs.java;h=4f812755b4f47698bb959acaa6ce1577edf2167e;hb=c08cf5bd42734df6ad8e557117cd366009e561cc#l193

In case, we want to set homeDir and not prefsDir, I suggest introducing a fallback after parsing the arguments and before opening the preferences at

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=ImageJA.git;a=blob;f=ij/ImageJ.java;h=4959abfa3bd35829d51608433e7797273a28ecc9;hb=c08cf5bd42734df6ad8e557117cd366009e561cc#l595

like

if ( Prefs.getHomeDir() != null && !Prefs.getHomeDir().equals("") && System.getenv("IJ_HOME") != null && !System.getenv("IJ_HOME").equals("") )  Prefs.setHomeDir(System.getenv("IJ_HOME"));

That is not failsafe in case that the paths are bogus but for testing that, we need to change Prefs where files are actually accessed.

I can look into that tomorrow...
Comment 10 Johannes Schindelin 2010-08-30 13:54:32 CDT
Yes, that workaround _should_ do the job.

I misread the code to assume that prefsDir is set from homeDir, but it is set to userHome (sorry for the confusion, I was mislead by the similar names).

My previous worry about the variable being set via -ijpath _before_ the first call to loadPrefs() are therefore moot.

I just wanted to make sure that Fiji works in the intended way even if you chose to use plain ImageJ instead of ImageJA (e.g. by calling Help>Update ImageJ to the daily build). But the only way to ensure that would be to set the property user.home ourselves, which might break other code in all kind of funny ways.

Anyhow, I am willing to go that route:

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=fiji.git;a=commitdiff;h=be8367179ef2874e9fcfb79452968819c28f8ad8;hb=refs/heads/ij-home

Could you test, please, and merge if everything seems right? Thanks. (/me has to run off to give a course for the rest of the day...)
Comment 11 Stephan Saalfeld 2010-08-30 14:15:11 CDT
I feel a bit cautious about setting System.user.home.  That might have undesired consequences for other applications (plugins?) that handle the problem otherwise.  We should stick with changing the path for saving ImageJ preferences which is not necessarily where people expect to be System.user.home.

That is, I would prefer a solution that either is what I suggested before or we set an additional property instead (e.g. System.ij.home) that is then used instead of System.user.home from the Prefs implementation.
Comment 12 Johannes Schindelin 2010-08-31 00:03:56 CDT
As I said, what you suggest implies changing ImageJA and leaves behind ImageJ. That is why _I_ am hesitant to implement this.
Comment 13 Johannes Schindelin 2010-08-31 00:53:02 CDT
Besides, calling it IJ_HOME (instead of IJ_PREFS_DIR, as I suggested) would imply that the home is redirected for ImageJ, not just the prefs directory.
Comment 14 Stephan Saalfeld 2010-08-31 11:04:31 CDT
I understand your concerns.  Still, changing a standard property (even a broken one) can have undesired consequences for all applications that run in the context of Fiji.  I was actually thinking about making this variable something that could also work for plain ImageJ because it provides a nice way to work with customized system-wide installations.  Should we suggest it to Wayne?

Otherwise, I am not completely against doing it as you suggested (what about $FIJI_USER_HOME ?).  But we need some big red warning signs in front of that property, just to protect ourselves against the resulting bug-reports.
Comment 15 Johannes Schindelin 2010-08-31 13:53:37 CDT
With the help of Stephan, I implemented this, committed it, pushed it, and uploaded a new ij.jar.

Now you can override the path to the directory where the preferences are read from/written to by setting the environment variable IJ_PREFS_DIR to the full path. Note: this directory _must already_ exist. ImageJA will not create it.

Here is the commit explaining things:

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=fiji.git;a=commitdiff;h=d146c0807b4cb2a8f14feebb78fd6b2043229b99

and here is the actual commit in ImageJA:

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=ImageJA.git;a=commitdiff;h=a861dffe935a18527d2709b46e4419aad0f777a1
Comment 16 Christian 2010-08-31 14:09:23 CDT
I like it! Works perfect
Thank you guys so much!