View Issue Details

IDProjectCategoryView StatusLast Update
0022624FPCFCLpublic2012-08-20 18:05
ReporterPaul Assigned ToMichael Van Canneyt  
Status closedResolutionfixed 
PlatformWindowsOSWindows 7 
Product Version2.6.0 
Target Version2.6.1Fixed in Version3.0.0 
Summary0022624: [Windows] GetAppConfigFile's SubDir parameter does not behave as documented
DescriptionOn 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
TagsNo tags attached.
Fixed in Revision939
Attached Files


related to 0020706 assignedJonas Maebe GetAppConfigDir delivers uncorrect path on Mac OS 


Jonas Maebe

2012-08-12 20:40

manager   ~0061598

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.


2012-08-12 21:00

reporter   ~0061600

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.

Jonas Maebe

2012-08-12 21:34

manager   ~0061601

Yes, but the question is whether it is really necessary to change the current behaviour at all. At least 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


2012-08-13 17:57

reporter   ~0061610

That's a valid point of view, however, it is leaving an inconsistency between different platforms.

Reading further on at e.g. 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?

Jonas Maebe

2012-08-14 11:58

manager   ~0061618

If anything needs to be changed regarding the extra subdirectory, it seems that it's the Windows behaviour. From the documentation at :

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.


2012-08-17 10:39

reporter   ~0061682

Yes, "GetAppConfigFile" gives different results on Windows 7. Here are some comparisons:

 OS X: <UserDir>/.config/<project>/
 Win7: <UserDir>\AppData\Local\<project>\
 OS X: <UserDir>/.config/<project>.cfg
 Win7: <UserDir>\AppData\Local\<project>\<project>.cfg
 OS X: <UserDir>/.config/<project>.cfg
 Win7: <UserDir>\AppData\Local\<project>\<project>.cfg
 OS X: <UserDir>/.config/<project>/<project>.cfg
 Win7: <UserDir>\AppData\Local\<project>\Config\<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?

Jonas Maebe

2012-08-17 10:50

manager   ~0061683

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)

Michael Van Canneyt

2012-08-20 00:16

administrator   ~0061736

Changed the description to make clear that one should not assume that the actual locations do not follow the same pattern on all OSes.


2012-08-20 18:05

reporter   ~0061767

OK, thank you.

Issue History

Date Modified Username Field Change
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