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

[Michael Van Canneyt]

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:

http://www.freepascal.org/docs-html/rtl/sysutils/getappconfigdir.html

Specifically

"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.

Michael.