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

[Michael Van Canneyt]

On Sat, 9 Feb 2013, Giuliano Colla wrote:

> Il 09/02/2013 10:25, Michael Van Canneyt ha scritto:
>> 
>> 
>> 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.
>> 
>
> I can easily accept that it's not a bug, but you must agree with me that it's 
> a problem.
>
> If every user application must include code between GetAppConfigxx and 
> TIniFile.Create to extract the path and ensure that it exists, even for the 
> trivial case Global=false, then it's reasonable that the right place for that 
> code is in system functions, and not in user application.

Yes. 
Like I said, we can imagine a parameter 'AllowCreate' or 'ForceCreate'.

Michael.