GNOME Bugzilla – Bug 390532
GKeyFile checks breaks existing applications
Last modified: 2007-01-10 12:59:05 UTC
Older versions of gnucash used to generate key files with spaces in the keys. Which means that with glib 2.12.6 it now fails to re-read them. The solution would be to allow spaces in key names. It is not very clean, but I don't think it does harm either.
Created attachment 79018 [details] [review] Add space to allowed key characters
hmm, space is a spectacularly bad character to allow in keys, if only because it won't work at the beginning or end of keys. Consider cases like: Name = foo # sets the key "Name", trailing space is stripped Name=bar # sets the key "Name", initial space is stripped Name [de] = bar # sets the de locale value for the key "Name "
Indeed, spaces around the = sign make it tricky. Do you have an idea of how to allow gnucash to re-read those old files then?
Convert them to an acceptable format before using gkeyfile to load them ? Should not be more than 5 lines, using g_file_[get|set)_contents() and the C equivalent of s/^ *// s/ *=/=/ s/ \([^=]*=\)/_\1/
I'm confused why Matthias Clasen says that spaces are a problem. According to gnucash upstream, before this change, \s was documented to be a matching space at the beginning or end of a key.
\s is only recognized in values, not in keys. This has not changed. What we are discussing here is problems with allowing literal spaces in keys.
Created attachment 79122 [details] [review] Accept space in key names with corresponding tests I personally wonder whether a localized key name with spaces at the end should be treated as such; this patch will support key names with a space in the middle but will refuse spaces at the end or the beginning of key names.
Created attachment 79126 [details] [review] Reverts stricter KeyFile checks and outputs critical warnings instead Perhaps it would be better to back off the backward-incompatible changes in GKeyFile and only outputs critical warnings during the 2.12 lifecycle? I've uploaded the attached patch to achieve this in Debian.
2007-01-01 Matthias Clasen <mclasen@redhat.com> * glib/gkeyfile.c: Convert the recently added stricter keyfile syntax checks into critical warnings, to help apps which do bad things with key files. Note that the stricter checks will remain in place for 2.14. (#390532, Loïc Minier) * tests/keyfile-test.c: Adapt
ok, from what i understand in here, i have a whole directory of files .desktop files that are ok however, without the patch in comment #8, nautilus for example doesn't want to pass on any file associations without the patch http://img89.imageshack.us/img89/2113/withoutmc8.png with the patch http://img101.imageshack.us/img101/7164/withpn6.png not just tar.gz files pngs, jpegs, truetype fonts, plain text files, etc... is it too strict?
The patch is in 2.12.7. However, the stricter checks remain in place in trunk. Applications need to be fixed to respect the file format
Matthias, what do you suggest for bug #394262 wrt this issue?
I recommend that the desktop entry spec be amended to allow /, +, -, _ in keys and whatever other characters happen to be used. That is not really a problem. Allowing space, however, is a bit problematic.
retitling