After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784664 - Avoid folding in ESourceMailIdentity::aliases property
Avoid folding in ESourceMailIdentity::aliases property
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.24.x (obsolete)
Other Linux
: Normal minor
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2017-07-07 18:33 UTC by Stephen
Modified: 2017-07-10 17:18 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stephen 2017-07-07 18:33:47 UTC
In the config. files storing email aliases ($XDG_CONFIG_HOME/evolution/sources/*.source) a literal "\n" then [tab] is inserted every 2-3 aliases (around the 80th column).

Presumably this should actually be a newline, and was just intended for config. file readability :)

It doesn't seem to break anything, and manually removing the literal "\n" or replacing it with an actual newline also doesn't seem to break anything, though any alias changes immediately put back the literal "\n" strings.
Comment 1 Milan Crha 2017-07-10 14:12:21 UTC
Thanks for a bug report. I'm not sure I understand the issue. Do you mean that some underlying private application file uses a format you think is incorrect, even though the application itself can work with that file without any issue?
Comment 2 Stephen 2017-07-10 14:28:04 UTC
Aliases for an Evolution email account are stored in (at least) files in the above mentioned location, e.g. ~/evolution/sources/1234567890.1234.1@hostname.localdomain.source

When several aliases are created for an account, they are written to a single line in the file as follows:

Aliases=alias1@example.com, alias3@example.com, alias3@example.com \n	alias4@example.com

The "\n" in the line above is not an escape character, it is a literal "\" and "n"

It's pretty easy to reproduce - add 4+ aliases to an account and then grep in that location for one of them, and have a look at the file's content.

This seems to be a bug in writing the aliases to the file, possibly from an attempt to visually format the aliases more nicely when written to file (the "\n" string is followed by a tab character).

It's correct that it seems not to be causing issues now, but that may be more luck than anything ;) In any case, I don't believe the intent is to actually write literal "\n" strings to the file.
Comment 3 Milan Crha 2017-07-10 17:18:15 UTC
I see. It's about folding and it's done in camel_internet_address_encode_address(), called through camel_address_encode() before setting the aliases in the UI. I didn't notice it, because I didn't use so many aliases when testing it. I wouldn't mind, as long as the provided functions are used, but I agree that it's a string property, where the folding should not be done, thus I changed it with:

Created commit 855d7d1 in evo master (3.25.4+)
Created commit 7ed45f5 in evo gnome-3-24 (3.24.4+)