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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
