bugGNU Octave - Bugs: bug #40444, On Windows, config & history...


bug #40444: On Windows, config & history files etc. should go to %APPDATA%

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Fri 01 Nov 2013 04:46:11 PM UTC  
Category:  Configuration and Build System Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Postponed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  Open
Release:  dev Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sat 09 Mar 2019 08:18:45 PM UTC, comment #19:

Sure I'll help. On which of the various bug reports do we continue discussion? (and maybe we'd better close all the other ones then, it's hard to follow a "distributed" discussion.)

Do you want to test "file #46450:  xdg.patch" in bug #36477/ after fixing therefs to APPDATA / app_data? Markus Muetzel already reported there.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 09 Mar 2019 05:54:14 PM UTC, comment #18:

I've been convinced that %APPDATA% is a good default for reading octaverc. That is also where the GUI will be storing its settings now (bug #55855). Still hoping someone can help test what I have so far.

Mike Miller <mtmiller>
Project Administrator
Sat 09 Mar 2019 08:20:28 AM UTC, comment #17:

One more vote for config going in %APPDATA% here. Speaking as someone who's worked in university computer labs and large businesses, your users really want that app config to be roaming.

From what I've seen, Windows apps generally store config data in %APPDATA%, and app cached data in %LOCALAPPDATA%.

Mike wrote:

> If a user saves their startup path to octaverc (e.g. with 'savepath'), that might include local directories and drives that are only present on one system. That should only happen in a local configuration file, not a roaming file.

In an institution/IT environment that has roaming profiles, the onus is on a combination of the users and IT staff to not do this. The user profile is configured to set up drive mappings so there is a consistent drive letter environment for the user across machines. Users are trained to stick with those commonly-available drives, and when something breaks due to them using a local drive, a quick conversation with IT will clear it up (usually ending in "don't do that").

> If Octave supports reading octaverc from %APPDATA% only, how would you add a startup configuration that only applies to one machine?

Add this to your roaming octaverc:

my_local_octaverc = [ getenv('LOCALAPPDATA') '\Octave\octaverc_local' ];
if exist ( my_local_octaverc )
  run (my_local_octaverc)

Same trick that bash users do to have machine-specific bashrcs when they have a synced ~/.bashrc.

Andrew Janke <apjanke>
Fri 08 Mar 2019 08:07:15 AM UTC, comment #16:

Looking in the %USERPROFILE%\Appdata subfolders on my PCs, I see that many programs utilize both .\Local and .\Roaming.
E.g., Mozilla Seamonkey (mail/browser suite) has it's cache in .\Local and the bookmarks and plugin stuff in .\Roaming.
Which matches Microsoft's explanation in the first URL in comment #9.

As to Mike's example, I think that the K:\MyFiles savepath scenario just brings up more question: e.g.,, what if K:\MyFiles happens to be on a thumbdrive that isn't there the next time Octave starts? what would Octave be supposed to do then, and does it then make a difference whether .octaverc containing the K:\MyFiles path line were in Appdata\Local or Appdata\Roaming?

(I really don't have a specific opinion on the whole thing; it's just what I see that most programs seem to do, and I'm not quite convinced that all those programs conform to the implicit or explicit rules)

Philip Nienhuis <philipnienhuis>
Project Member
Thu 07 Mar 2019 10:51:32 PM UTC, comment #15:

@Mike: I can surely follow your logic but I'm wondering how important or serious the issue you bring up is.

In networks / domains with roaming profiles, one usually has no "individual" PCs where a specific location either exclusively exists or isn't available. I suppose most IT depts. go to great lengths to make work environments independent of location and/or specific clients.
I can think of laptops that can connect to a network where the scenario you bring up may lead to issues, but then again a user would (should) know what the cause is and act accordingly.
And AFAIK savepath can be given a filename to save the path to.

AFAIK the main difference between Appdata\Local and Appdata\Roaming is that the former has a .\Temp subdir for volatile files.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 07 Mar 2019 10:05:26 PM UTC, comment #14:

Yeah, I see that, QSettings uses either the Windows registry or the roaming %APPDATA% by default, but then uses %LOCALAPPDATA% for QStandardPaths::AppConfigLocation. I agree that's inconsistent and I don't see an explanation.

If y'all agree that %APPDATA% is the only right solution, I'll update my patch, but still appreciate testing as is. And if we do want to avoid using the registry for Qt settings, we should try to be as consistent as possible so we don't have to have more than 1 or 2 directories where config files might be stored.

So back to my example with 'savepath', if a user adds 'K:\MyFiles' to their path and calls 'savepath', that should be saved in the roaming %APPDATA% directory?

Mike Miller <mtmiller>
Project Administrator
Thu 07 Mar 2019 09:31:45 PM UTC, comment #13:

The comparison of QStandardPaths is convincing. But then I don't get why QSettings uses %APPDATA% or ~/.config but in QStandardPaths, ~/.config and %LOCALAPPDATA% have the same purpose. IMHO, this is not consistent.

Torsten Lilge <ttl>
Project Member
Thu 07 Mar 2019 09:29:30 PM UTC, comment #12:

But if it's really important that it be %APPDATA% and using %LOCALAPPDATA% is completely useless, then I will give in and use it.

So far my understanding is that %LOCALAPPDATA% is useful for configuration that you might want to be machine-specific. If instead it's actually for things that can be completely discarded like cache files or trash files, then I'll adjust my understanding.

I just want to make sure we define these directories correctly across all platforms. On GNU/Linux, XDG gives us the concept of a cache directory, a config directory, and a data directory, and Qt is leading me to believe that these correspond to %LOCALAPPDATA%/AppName/cache, %LOCALAPPDATA%/AppName, and %APPDATA%/AppName. But XDG doesn't have a concept of "local" vs "roaming", it's more about the content and type of the file.

Mike Miller <mtmiller>
Project Administrator
Thu 07 Mar 2019 09:18:16 PM UTC, comment #11:

Thanks for the info and the references. Based on that and on the Windows article, I still think that %LOCALAPPDATA% is a better first target for where to read octaverc from.

If a user saves their startup path to octaverc (e.g. with 'savepath'), that might include local directories and drives that are only present on one system. That should only happen in a local configuration file, not a roaming file.

I am also trying to reconcile this with best practices. One example is the Qt QStandardPaths class (https://doc.qt.io/qt-5/qstandardpaths.html), which maps various system conventions to a standard enumerated type. According to QStandardPaths

  • AppDataLocation == %APPDATA%/AppName
  • AppConfigLocation == %LOCALAPPDATA%/AppName

On a GNU system

  • AppDataLocation == ~/.local/share/AppName
  • AppConfigLocation == ~/.config/AppName

In this context, "app data" to me means things like icons, themes, fonts, compiled search databases, email folders, various kinds of internal storage or generated files. OTOH "app config" means configuration files that users should be able to edit and customize to configure the application for their local environment.

If Octave supports reading octaverc from %APPDATA% only, how would you add a startup configuration that only applies to one machine?

I am leaving open the possibility that Octave could read octaverc from both locations eventually, but for now I think %LOCALAPPDATA% is a good first target to aim for. Can you test my patch on bug #36477?

Mike Miller <mtmiller>
Project Administrator
Thu 07 Mar 2019 09:07:41 PM UTC, comment #10:

From the docs for QSettings, it is %APPDATA% where Qt creates a settings file on windows (https://doc.qt.io/qt-5/qsettings.html#platform-specific-notes).

Torsten Lilge <ttl>
Project Member
Thu 07 Mar 2019 08:07:27 PM UTC, comment #9:

On most Windows 7+ systems software settings and init files are stored in %APPDATA% (which usually points to %USERPROFILE%\Appdata\Roaming) rather than %LOCALAPPDATA% (which points to %USERPROFILE%\Appdata\Local).

I think ...\Appdata\Roaming is a better choice because e.g., company networks usually make use of roaming profiles anyway so users can have their favorite Octave settings anywhere, and for isolated pc's (and home networks) there's no functional difference between Appdata\local and Appdata\Roaming. More info here:



Philip Nienhuis <philipnienhuis>
Project Member
Wed 06 Mar 2019 07:56:34 PM UTC, comment #8:

At the moment I plan to add support for reading octaverc from %LOCALAPPDATA%, because that seems to be the most specific and therefore safest. In the future we could add support for reading a startup file from %APPDATA% first, and then %LOCALAPPDATA%, if either one or the other or both exist.

This bug is unfortunately very wide-ranging and the solutions will come iteratively as separate parts of Octave are updated. It would be very helpful if there were distinct bugs for each feature (startup files, history files, Qt settings files, local pkg installations).

There are already

  • bug #36477 - read startup files from alternate locations
  • bug #55822 - read Qt settings files from alternate locations

Neither of these are about history files or pkg installation or metadata locations. History and pkg locations can be configured at will by the user in the startup file, so making the startup file more flexible is the first priority.

Mike Miller <mtmiller>
Project Administrator
Thu 17 Jan 2019 09:17:59 AM UTC, comment #7:

Just a cross-reference note: there's also bug #44548, which is discussing where `pkg` installs its per-user stuff, which is a similar concern. There are roles for both %APPDATA% and %LOCALAPPDATA% here.

I think this bug's discussion is probably right in that Octave config settings, and perhaps command history, should go in the user's roaming profile in %APPDATA%. Installed programs and data files should probably be computer-local and go in %LOCALAPPDATA%, and that database shouldn't be shared. Sharing command history files is problematic, though, since they change often and there's no merge logic for them; most systems I'm familiar with store those machine-locally. So .octave_history should probably go in %LOCALAPPDATA%.

One note: whatever you decide, you shouldn't locate these directories by looking at %USERPROFILE%. The AppData and AppDataLocal directories and other special Windows shell folders can be "relocated" independently of the root folder for the user profile. Use %APPDATA% to find the Roaming Application Data directory and %LOCALAPPDATA% to find the Local Application Data.

Andrew Janke <apjanke>
Mon 21 Aug 2017 03:45:07 PM UTC, comment #6:

If this was adapted, it should also support user names with non-ASCII characters on Windows.
Adding bug #49118 as a dependency for the Windows part.

Markus M├╝tzel <mmuetzel>
Project Member
Sun 22 Feb 2015 01:35:48 AM UTC, comment #5:

Agree with Philip's last comment, this should be solved the same way for both GUI and CLI. So this should probably depend on a new library routine that declares where configuration files and history files are stored. This routine should be callable for all operating systems and return the appropriate directory for Unixy systems (based on XDG_CONFIG_HOME) and for Windowsy systems (based on APPDATA).

Adding dependency on bug #36477.

Mike Miller <mtmiller>
Project Administrator
Sun 19 Jan 2014 08:45:08 PM UTC, comment #4:

Yes, but for the CLI version of Octave this should also be adapted.

I think it had better be done in core sensu stricto Octave itself, not only in the GUI section.

Oh and I had no time (esp. at work, where I've hit this repeatedly in the past) to investigate further :-(

Philip Nienhuis <philipnienhuis>
Project Member
Sun 19 Jan 2014 07:54:42 PM UTC, comment #3:

Concerning the configuration file, the default behavior of qt is to put the file into the "standard location" on each platform as described here: http://qt-project.org/doc/qt-4.8/qsettings.html#platform-specific-notes
Switching to this default behavior should not be very difficult.

Torsten Lilge <ttl>
Project Member
Wed 06 Nov 2013 09:37:16 PM UTC, comment #2:

For some reason this patch doesn't work (anymore?)

I'll investigate

Philip Nienhuis <philipnienhuis>
Project Member
Sat 02 Nov 2013 02:40:19 PM UTC, comment #1:

As regards the history file, this can easily be fixed in octaverc (main-rcfile), so I've prepared a changeset for that. (I've used a similar fix, with no error catching, for years at work)

Patching the Qt GUI setting files is beyond me :-(

(file #29527)

Philip Nienhuis <philipnienhuis>
Project Member
Fri 01 Nov 2013 04:46:11 PM UTC, original submission:

Presently Octave writes config & history files to the "root" of the user profile, as customary on *nix.

From what I know, on Windows the root of the user profile is mainly used by the system and not really intended for users or user programs (although I haven't seen an official spec for this).
I'm not sure that the root of %USERPROFILE% is a good location at all; I repeatedly met problems with Octave's history file there that -perhaps! guessing...- could be related to this location (bug #40443).

On Windows systems, software settings etc. are supposed to go to program-specific subdirs in the "Application Data" subfolder in the user profile; it can be obtained by the environment string APPDATA.
E.g., 'getenv ("APPDATA")' on my fairly standard Win7 box gives
'C:\Users\Philip\Application Data\Roaming\Octave';
On a "plain vanilla" XP box it is:
'C:\Documents and Settings\{username}\Application Data'

I think it would be better if Octave on Windows systems complies to this.
FYI, AFAIK spaces in the path names don't matter for data files; spaces only induce problems when appearing in path names to executables and include files and the like. E.g., Octave happily handles scratch files in '%USERPROFILE%\Local Settings\Temp'

See also bug #36477 where analogous requests are made for *nix systems (freedesktop.org).

Philip Nienhuis <philipnienhuis>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #29527:  octaverc_win_hist.cset added by philipnienhuis (2KiB - application/octet-stream)


   bug dependencies.

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by apjanke (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-06 mtmiller Carbon-CopyRemoved 80942 => -
    2017-08-21 mmuetzel Dependencies- => Depends on bugs #49118
    2017-08-08 mtmiller Dependencies- => bugs #51684 is dependent
    2016-06-07 lachlan Dependencies- => bugs #48095 is dependent
    2015-02-22 mtmiller Severity2 - Minor => 1 - Wish
        StatusPatch Submitted => Postponed
        Dependencies- => Depends on bugs #36477
    2014-01-19 mtmiller CategoryNone => Configuration and Build System
    2013-11-02 philipnienhuis Attached File- => Added octaverc_win_hist.cset, #29527
        StatusNone => Patch Submitted

    Back to the top

    Powered by Savane 3.4