File bindings don't work with GLib 2.77.3

[sachahony]

I have updated my glib2 from 2.77.2 to 2.77.3. After the update I can no longer enter into tar.bz2 files. Reverting back 2.77.2 solves the issue. Also the view archive shows a "binary" view rather than a "direcory" as if the file is not recognised.

Changelog of glib: ​https://download.gnome.org/sources/glib/2.77/glib-2.77.3.news

[andrew_b]

Are any other regressions with glib-2.77.3 besides tar?

Why component is mcview?

[andrew_b]

The significant change in GLib-2.77.3 is ​gkeyfile: Fix overwriting of GError.
Commit ​71b7efd08.

Solution: escape backslashes in mc.ext.ini: replace single \ with double one: \\.

[Toolybird]

We just hit this in Arch Linux because that commit made it into stable release glib2-2.76.5

[dimich]

I can confirm the issue with glib-2.76.5 in Arch: ​https://bbs.archlinux.org/viewtopic.php?pid=2118521

Not only compressed tar archives affected but other suffixes too, e.g. .mp4, .odt

[zaytsev]

Oh man, why they would handle escape sequences in INI files in the first place o_O ?

Maybe we can just switch from g_key_file_get_string to g_key_file_get_value API, because otherwise every stupid backslash would have to be escaped and it will make a bloody hell out of our regexes.

[ossi]

the ini parser is also used to parse .desktop files and such stuff, so supporting escapes in strings makes perfect sense.

it is a bit surprising that such a seemingly obvious bugfix has such side effects. i guess mc does something ... "interesting"?

[andrew_b]

Replying to zaytsev:

Maybe we can just switch from g_key_file_get_string to g_key_file_get_value API, because otherwise every stupid backslash would have to be escaped and it will make a bloody hell out of our regexes.

g_key_file_* API is used in mc indirectly via mcconfig engine. Changing g_key_file_get_string to g_key_file_get_value in mcconfig may break the handling of other INI files.

We already have INI files with escaped backslashes: mc.lib, Syntax (it is not INI but nonetheless), probably some others. I think mc.ext.ini should be consistent with them.

[zaytsev]

it is a bit surprising that such a seemingly obvious bugfix has such side effects. i guess mc does something ... "interesting"?

I'm not sure I would define this as "interesting". I think it's just missing error handling, the usual C stuff.

We already have INI files with escaped backslashes: mc.lib, Syntax (it is not INI but nonetheless), probably some others. I think mc.ext.ini should be consistent with them.

You are right, but exactly for this reason I find them to be disgusting and actually see no reason why we should support escape sequences in the configuration files. So I'd rather break everything while we are at it :-) But it's up to you.

[andrew_b]

Probably the story isn't finished yet: ​https://gitlab.gnome.org/GNOME/glib/-/issues/3095

[zaytsev]

​https://gitlab.gnome.org/GNOME/glib/-/issues/3094

[andrew_b]

Ticket #4505 has been marked as a duplicate of this ticket.

[birdie]

I thought I was going crazy. Thanks, Andrew.

[birdie]

A quick temporary fix for the affected users:

sudo cp -a /etc/mc/mc.ext.ini /etc/mc/mc.ext.ini.bak
sudo sed '/Regex=/s/\\/\\\\/g' -i /etc/mc/mc.ext.ini

[andrew_b]

So, I propose the following:

• escape backslashes in mc.ext.ini to be consistent with other files were regexps are used;
• use g_key_file_get_value instead of g_key_file_get_string to avoid parsing of key value in GLib.

Replying to zaytsev:

actually see no reason why we should support escape sequences in the configuration files

Escape sequence is a part of key definition for various terminals: https://midnight-commander.org/browser/misc/mc.lib#L15

[andrew_b]

Branch: 4502_mc.ext.ini
Initial changeset:2da7ef347d1c48e4ad8e73f5135cfe8a363e6c1f

[andrew_b]

Some tests failed.

[andrew_b]

The usage g_key_file_get_value instead of g_key_file_get_string requires a lot of changes in test. Let's leave it as it is.

[andrew_b]

Merged to master: [e8c4677b7e10c43f673e6542a86d3ea3ccf4f95e].