[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.

Michael Van Canneyt michael at freepascal.org
Sat Feb 9 10:25:27 CET 2013

On Sat, 9 Feb 2013, Reinier Olislagers wrote:

> On 9-2-2013 1:49, Giuliano Colla wrote:
>> It turned out that the reason was simply that the default AppConfigDir
>> (~/.config/ ) wasn't there, and therefore in the two usual lines
>> AppConfigFileName:= GetAppConfigFile(False);
>> ini := TIniFile.Create(AppConfigFileName);
>> the second line was generating the access violation.
>> Desktop specs tell where configuration data should go, but they don't
>> guarantee that the directory exists. Other applications take care of
>> creating if it doesn't exist, but its presence depends on which
>> applications you launch.
>> Of course, once one knows, one can use ForceDirectories in the
>> application code, but it would be much more user friendly if
>> XdgConfigHome (or SysConfigDir when it will be implemented) in sysutils
>> took care of that. You ask for the default configuration path to put
>> your data in, and you get a sane and *existing* path.
>> It would also be nice if TIniFile.Create didn't generate an Access
>> Violation if the file can't be created.
>> Should I open an issue on the bugtracker on this subject, or I'm the
>> only one to think that it's a bug/required feature?
> If I were you, I'd open an issue. I agree this is a problem.

It is not a problem.

You should READ the documentation when using functions:



"This does not mean that the directory exists, or that the user can write in this directory (especially if Global=True).
   It just returns the name of the appropriate location."

So it is not a bug.

We can maybe have an appropriate 'AllowCreate' or 'EnsureDir' parameter or so. 
But for system config directories, this is nonsense, so it should be optional.


More information about the fpc-pascal mailing list