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

[Giuliano Colla]

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.

Maybe the right thing to fix isn't GetAppConfigxx, but TInifile.Create, 
which doesn't return any warning if the file path doesn't exist, and 
will just SigSev on a subsequent ini.WriteWhatever.

TIniFile silently creates the file if it doesn't exist, letting you 
think that it takes care of everything, then why shouldn't it also 
create the path if it doesn't exist? (provided it's writable, of course, 
but Global=true requires special handling in any case, it's not for 
everybody).

Giuliano