Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1039 Settings in Windows network with shared desktops

open
Windows (184)
6
2011-05-23
2011-05-19
Daniel Polansky
No

In Windows, FreeMind stores its settings in getProperty("user.home") + ".freemind". That is different from the customary Windows location for application data, which is in Windows Vista typically ~\AddData\Roaming\FreeMind for an app called "FreeMind", without the leading dot and with proper capitalization, on the model of what most applications do. Above all, Java's "user.home" is plagued by a long-standing Java bug that is unlikely to get fixed any soon: the Java determines the value of "user.home" by going to the location of user's desktop and stripping off the last part. In a Windows network environment that uses shared desktops, each user has the same desktop folder, which leads to FreeMind using the same settings folder for each of the users, which is wrong.

Fixing this bug requires proper research that I have not done yet. Going to getProperty("user.home") + "\AppData\Roaming\FreeMind" does not work, as getProperty("user.home") is plagued by the Java bug.

The Java bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4787931

Concerned FreeMind versions: 0.9.0, 0.8.1, 0.7.1, and all earlier.

Workaround: I do not know any, but maybe there is one.

Other bug reports similar to this one:

.freemind relative to 'desktop' directory..., 2009-05-25
http://sourceforge.net/tracker/index.php?func=detail&aid=2796432&group_id=7118&atid=107118

home directory incorrectly read, 2008-04-13
http://sourceforge.net/tracker/index.php?func=detail&aid=1941615&group_id=7118&atid=107118

--Dan

Discussion

1 2 > >> (Page 1 of 2)
    • priority: 5 --> 6
     
  • To diagnose whether this bug causes problems for a user, let him try run this from a DOS console:

    REG QUERY "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" /v Desktop

    The result is a path to desktop that Java uses to determine the value of "user-home".

    See also

    http://freemind.sourceforge.net/wiki/index.php/Home_folder

    --Dan

     
  • Hi Dan,

    fixed in git commit 5b174744ec4e3443691e9de5010a8f7289672e4f.
    The bug was easily reproducible moving the /home/user directory away in linux.
    I will publish a next alpha soon.

    Best regards, Chris

     
    • assigned_to: dpolivaev --> christianfoltin
     
  • A solution would be to use Duser.home=d:\whereever in the bat file

     
  • Hello Chris, from what I can see in the diff

    http://freemind.git.sourceforge.net/git/gitweb.cgi?p=freemind/freemind;a=commitdiff;h=5b174744ec4e3443691e9de5010a8f7289672e4f

    the problem described in this bug has not really been fixed. What you seem to have fixed is the impossibility to close FreeMind 0.9.0 when FreeMind fails to create the log file. Having this fixed is good, but that is not what this bug report describes. This bug report points out that users working in a Windows environment with shared desktops will have shared settings, shared mind map backups, what not. An undesirable consequence is this: when Adam saves his settings and goes home, Bob starts FreeMind, Bob adjusts settings as he sees fit, saves the settings and goes home, and Adam comes next day and starts FreeMind, then Adam gets FreeMind opened with Bob's settings. Worse yet, before your fix, the user at least had a hint that something went wrong by having trouble closing the app. After your fix, everything will appear alright to the user until the time at which he will find his settings overwritten for no apparent reasons, puzzling about what could have gone wrong.

    In order to get this properly fixed, we need to figure out how to get to "C:\Users\User name\AppData\Roaming", and store FreeMind settings there in "...\Roaming\FreeMind\auto.properties" and the like, just like most apps do in Windows.

    Workaround: From what I have understood from your last post, there is a workaround: let the users in such an environment modify their Freemind.bat by adding "-Duser.home=desired_location", and then run Freemind from the batch.

    I have set the priority to "6", as only a fraction of all users is concerned, and there is a workaround.

    --Dan

     
    • status: open --> pending
     
  • Hi,

    please try out, if the error got fixed in the FM 1.0.0 Alpha4 version (use the zip version and remove it after the try, this is not proposed for productive use).

    TIA, Chris

     
  • Hello Chris, I have no access to a Windows environment with shared desktops, so I do not know how to reproduce that the bug has been fixed in an enviroment with a shared desktop. What I can test is whether FM 1.0.0 Alpha4 stores FreeMind settings at "AppData". From what I can see from the diffs in Git, no changes have been made in the code that would lead to this, but I can try anyway.

    Steps used to find out whether the bug or issue has been fixed:
    1. Download FM 1.0.0 Alpha 4 and unzip it
    2. Run FM 1.0.0 Alpha 4
    3. Change one setting and close FM
    4. Look at C:\Users\<user name>\AppData\Roaming
    5. Observation: No folder "FreeMind" has been created in "AppData\Roaming"
    6. Run FM 0.9.0
    7. Observation: The changed setting applies to FM 0.9.0. Thus, the settings of FM 1.0.0 Aplha 4 are stored in the old folder ".freemind".

    Maybe this should not be filed as a "bug" but rather as an "issue"; I was hesitating when creating this tracker item. This should not be hurried up: a change of settings folder in Windows is a significant one, in which users migrating to new version of FreeMind should be supported by being asked whether they want to get their settings and data copied from "<home>/.freemind" to "<appdata>/FreeMind"; if they answer "no", then "<appdata>/FreeMind" would be created anew, ignoring the settings in the old ".freemind".

    This is not urgent: a small fraction of users is concerned, and there is a workaround.

    Can you describe the steps that I should use to reproduce that the bug has been fixed? It still seems to me that you have fixed some bug or issue, but not the one that is described in this tracker item.

    Could FreeMind print to stdout where the log files are located? When I run Freemind.bat, the batch output contains almost no messages, as most of them end up in the log. What I think would really help in diagnosing various problems is if FreeMind, after just starting, would write to stdout something like this: "FreeMind home folder: C:\Users\&lt;user>\.freemind". Or it could write "Logging errors into C:\Users\&lt;user>\.freemind\log.0". You get the idea.

    --Dan

     
    • status: pending --> open
     
1 2 > >> (Page 1 of 2)