Menu

#2228 User-set cache location reset to default by itself

nextrelease
open-fixed
nobody
None
5
2019-12-18
2019-12-16
No
  1. Using the Tools -> Cache -> Move Cache... option, the location of the cache had been changed.
  2. Sometime in or prior to July 2019, the cache location apparently reset itself back to the ~/autoplot_data/fscache/ default location.

Discussion

  • Jeremy Faden

    Jeremy Faden - 2019-12-18

    This was broken last summer when I made the ~/autoplot_data/config/options.properties file be the authoritative control for the properties. I moved my cache from the default position and it seems to be persistent between sessions. Is this the case for you, Ivar?

    I think the confusion came when I first migrated prefs from org/virbo/autoplot/ to org/autoplot, and then again from the Java prefs area to the autoplot_data/config area.

     
  • Jeremy Faden

    Jeremy Faden - 2019-12-18

    I made my fscache location /tmp/jbf/fscache. This is a useful way to see how things are stored on Linux:

    ~/.java/.userPrefs
    spot7> find . -name '*.xml' -exec grep '/tmp/jbf' {} \; -print
      <entry key="fscache" value="/tmp/jbf/fscache"/>
    ./org/autoplot/datasource/prefs.xml
      <entry key="fscache" value="/tmp/jbf/fscache"/>
    ./org/virbo/datasource/prefs.xml
    

    Also, I'm not sure the fscache location should be stored in the autoplot_data/config preferences, since I'd like for one to be able to move the whole folder from one machine to another when they get a new laptop. Having a reference to a particular directory might break this.

     
  • Jeremy Faden

    Jeremy Faden - 2019-12-18

    Here;'s a procedure that shows the bug:
    1. move autoplot_data aside.
    2. rm -r ~/.java/.userPrefs
    3. get old autoplot from Jeremy, for example ~/bin/autoplot.20160728a.jar
    4. start this autoplot, reset the cache to /tmp/ap/fscache/
    5. start the latest version of autoplot
    6. note that the default location is used.

     
  • Jeremy Faden

    Jeremy Faden - 2019-12-18
    • status: open --> open-fixed
     
  • Jeremy Faden

    Jeremy Faden - 2019-12-18

    Okay the problem was the "get" method of the migrate prefs would use the default if the first preferences didn't contain the item. Now the code will check the second to see if it has the preference, then use the default. So this should be fixed in the next release.