View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0022624||FPC||FCL||public||2012-08-12 15:45||2012-08-20 18:05|
|Reporter||Paul||Assigned To||Michael Van Canneyt|
|Target Version||2.6.1||Fixed in Version||3.0.0|
|Summary||0022624: [Windows] GetAppConfigFile's SubDir parameter does not behave as documented|
|Description||On e.g. Windows 7 the following two calls|
from "sysutils" show results like
which is ok since the project config file is placed in the project config directory.
On OS X we get results like
and here "GetAppConfigFile" does not use the path returned by "GetAppConfigDir". The expected result for "GetAppConfigFile" is
|Tags||No tags attached.|
|Fixed in Revision||939|
Well, it's not a complete duplicate. This behaviour is the same on Linux.
A big problem is that if we change this, all programs compiled with new versions of FPC will suddenly no longer find their old configuration files because they will be stored in a different directory.
OK, but one question is if there are already more applications that would be (temporarily negatively) affected by this fix or if there would be (in the future) more applications that could benefit from a fixed behaviour.
This fix could be postponed to the next major release (2.8?) of FPC where it would be explicitely mentioned in the release notes.
Yes, but the question is whether it is really necessary to change the current behaviour at all. At least http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html says "$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used."
It doesn't say that configuration files must or even should be stored in a subdirectory of .config
That's a valid point of view, however, it is leaving an inconsistency between different platforms.
Reading further on at e.g. http://wiki.freepascal.org/Multiplatform_Programming_Guide one can see, that for fpc-2.2 the inconsistency did not exist. It could be interesting to read about the reasons of that change.
But further more in that wiki guide it is written that "Under Mac OS X, in most cases config files are preference files, which should be XML files with the ending ".plist" and be stored in /Library/Preferences or ~/Library/Preferences with Names taken from the field "Bundle identifier" in the Info.plist of the application bundle. Using the Carbon calls CFPreference... is probably the easiest way to achieve this. .config files in the User directory are a violation of the programming guide lines."
Especially the last sentence implies that GetAppConfigDir and GetAppConfigFile violate Apple's programming Guide Lines, and thus should be fixed. Would that be the right action to take in order to fix this issue?
If anything needs to be changed regarding the extra subdirectory, it seems that it's the Windows behaviour. From the documentation at http://www.freepascal.org/docs-html/rtl/sysutils/getappconfigfile.html :
GetAppConfigFile returns the name of a file in which the application can store its configuration parameters. The Global parameter determines whether it is a global configuration file (value True) or a personal configuration file (value False). The parameter SubDir, in case it is set to True, will insert the name of a directory before the filename. This can be used in case the application needs to store other data than configuration data in an application-specific directory. Default behaviour is to set this to False.
I.e., GetAppConfigFile(false) should return a path without the application name used as subdirectory at the end, while GetAppConfigFile(false,true) should return it with that extra directory. It works like that on Unix platforms, but not on Windows if I understand your report correctly (I don't have Windows). Is there no difference on Windows then between GetAppConfigFile(false,false) and GetAppConfigFile(false,true)?
Regarding putting preference files in Preferences on Mac OS X: that is what the related bug report is all about. I plan to implement that, but it will not be enabled by default (Mac OS X is a hybrid system, and depending on the kind of application either ~/.config or (~)/Library/Preferences is appropriate). I intend to the enable the -WC/-WG (create console/gui application) command line switches in the future for the Darwin target, which will switch between the two behaviours.
Yes, "GetAppConfigFile" gives different results on Windows 7. Here are some comparisons:
OS X: <UserDir>/.config/<project>/
OS X: <UserDir>/.config/<project>.cfg
OS X: <UserDir>/.config/<project>.cfg
OS X: <UserDir>/.config/<project>/<project>.cfg
So, the related issue tracks the behaviour on OS X and will reflect the difference between console and gui application.
Could you adress this issue to the Windows platfrom or should I close this issue and file another one for tracking this behaviour on the Windows platform?
I've updated the bug title. Note that it's possible that FPC's behaviour also conforms to standard behaviour on Windows (maybe you're never supposed to directly write your files directly in \AppData\Local\), but in that case it's still a documentation issue.
In any case, if you need a subdirectory you can simply pass the second "true" parameter and you'll always get one. The fact that the directory structure isn't identical on Windows and Unix platforms shouldn't matter (it will also be completely different from Windows when ~/Library/Preferences and/or ~/Library/Application Support/<project> is used on Mac OS X)
||Changed the description to make clear that one should not assume that the actual locations do not follow the same pattern on all OSes.|
||OK, thank you.|
|2012-08-12 15:45||Paul||New Issue|
|2012-08-12 15:45||Paul||Widgetset||=> Carbon|
|2012-08-12 20:09||Maxim Ganetsky||Project||Lazarus => FPC|
|2012-08-12 20:38||Jonas Maebe||Relationship added||duplicate of 0020706|
|2012-08-12 20:38||Jonas Maebe||Duplicate ID||0 => 20706|
|2012-08-12 20:38||Jonas Maebe||Status||new => resolved|
|2012-08-12 20:38||Jonas Maebe||Resolution||open => duplicate|
|2012-08-12 20:38||Jonas Maebe||Assigned To||=> Jonas Maebe|
|2012-08-12 20:40||Jonas Maebe||FPCOldBugId||=> 0|
|2012-08-12 20:40||Jonas Maebe||Note Added: 0061598|
|2012-08-12 20:40||Jonas Maebe||Assigned To||Jonas Maebe =>|
|2012-08-12 20:40||Jonas Maebe||Status||resolved => new|
|2012-08-12 20:40||Jonas Maebe||Resolution||duplicate => open|
|2012-08-12 20:40||Jonas Maebe||Product Version||1.1 (SVN) =>|
|2012-08-12 20:40||Jonas Maebe||Relationship replaced||related to 0020706|
|2012-08-12 20:40||Jonas Maebe||Category||LCL => FCL|
|2012-08-12 20:41||Jonas Maebe||Summary||[Darwin] GetAppConfigFile gives incorrect result => [UNIX platforms] GetAppConfigFile gives incorrect result|
|2012-08-12 21:00||Paul||Note Added: 0061600|
|2012-08-12 21:34||Jonas Maebe||Note Added: 0061601|
|2012-08-13 17:57||Paul||Note Added: 0061610|
|2012-08-14 11:58||Jonas Maebe||Note Added: 0061618|
|2012-08-17 10:39||Paul||Note Added: 0061682|
|2012-08-17 10:44||Jonas Maebe||OS||=> Windows 7|
|2012-08-17 10:44||Jonas Maebe||Platform||=> Windows|
|2012-08-17 10:44||Jonas Maebe||Product Version||=> 2.6.0|
|2012-08-17 10:44||Jonas Maebe||Summary||[UNIX platforms] GetAppConfigFile gives incorrect result => [Windows] GetAppConfigFile's SubDir parameter does not behave as documented|
|2012-08-17 10:50||Jonas Maebe||Note Added: 0061683|
|2012-08-17 13:22||Jonas Maebe||Status||new => assigned|
|2012-08-17 13:22||Jonas Maebe||Assigned To||=> Michael Van Canneyt|
|2012-08-20 00:16||Michael Van Canneyt||Fixed in Revision||=> 939|
|2012-08-20 00:16||Michael Van Canneyt||Status||assigned => resolved|
|2012-08-20 00:16||Michael Van Canneyt||Fixed in Version||=> 2.7.1|
|2012-08-20 00:16||Michael Van Canneyt||Resolution||open => fixed|
|2012-08-20 00:16||Michael Van Canneyt||Note Added: 0061736|
|2012-08-20 00:16||Michael Van Canneyt||Duplicate ID||20706 => 0|
|2012-08-20 00:16||Michael Van Canneyt||Target Version||=> 2.6.1|
|2012-08-20 18:05||Paul||Status||resolved => closed|
|2012-08-20 18:05||Paul||Note Added: 0061767|