GNOME Bugzilla – Bug 356176
importing .vcf replaces line breaks with literal \n in NOTE
Last modified: 2007-08-14 14:21:06 UTC
Please describe the problem: Importing the attached .vcf leads to a contact which has too many line breaks after a line which contains backslashes. This problem was found when testing SyncEvolution 0.4 with Garnome 2.16.0 instead of 2.14.3 which (like all previous Evolution versions) works as expected. The .vcf is one of the test cases with which I test the correct import/export of contacts via the libebook API. This means that the problem is not caused by the GUI, although it can be reproduced using it. Steps to reproduce: 1. import the attached .vcf into a local address book 2. look at it: there should be two empty lines after "backslash \" What is there instead is "backslash \ \n\n\n" and no empty lines. You can also export it to compare the .vcf, the exported .vcf is different. Actual results: \n instead of line break. Expected results: Does this happen every time? Yes. Other information:
Created attachment 72872 [details] .vcf with special NOTE that is not imported correctly
Minor update: with Evolution 2.6 from Garnome 2.14.3 the same .vcf is also not imported correctly. Instead of two line breaks after the literal backslash there's only one. With Evolution 2.6 from Debian testing this problem does not occur. Tests done on different machines, so I cannot rule out differences in the environment. Please let me know if you cannot reproduce it and need more information.
Please ignore comment #2 - the correct result is indeed _one_ empty line after "backslash \", which is consistent with the .vcf content of "backslash \\\n\n". In my report I have mentioned both too many and not enough line breaks. Retesting it resulted in not enough line breaks and literal "\n" in the text (as the issue title says), but I cannot rule out that the result is random.
I think this was broken by the fix for another bug (#334179), but that's irrelevant now. The attached patch fixes the problem. It occurs each time a backslash stands at the end of a line in the vcard, which can happen due to folding. In the original test.vcf this was not yet the case, but it happened when reencoding it and sending it to E-D-S. The problematic line then looked like this: 8 9 10 11 12 13 14 15 16\n\ncomma \,\ncolon :\nsemicolon \;\nbackslash \ \\n\nThe same\, in the middle of a line:\ncomma \, comma\ncolon : col The fix is to skip over folding by calling skip_newline() to find the next real character after a backslash: $ diff -c e-vcard.c.orig e-vcard.c *** e-vcard.c.orig 2006-09-30 07:15:56.000000000 +0200 --- e-vcard.c 2006-10-19 17:40:05.693936530 +0200 *************** *** 273,278 **** --- 273,282 ---- g_string_append_c (str, '\\'); break; } + /* beware, there might be a line break due to folding, + * need next real character + */ + lp = skip_newline(lp, quoted_printable); switch (*lp) { case 'n': g_string_append_c (str, '\n'); break; case 'N': g_string_append_c (str, '\n'); break; Can someone please apply this to the 2.8 maintenance branch and HEAD? I don't have commit rights.
Ping? Can someone please review the bug and apply the patch?
Ping. Ditto here too!
Created attachment 86786 [details] Image of rendered vcf with with suggested patch. Seems that patch improves situation but does not fix it completely. Take a look on screenshot of the vcard with rendered with the patch. I still have some \n and \ (in red rectangular) which should no be there...
After saving the contact to a .vcf file, I'm seeing something like this: 1440 EST\ \\n\\n\\nnCalled Not only "\n" but "\\n". This with without a patch using: gnome-extra/evolution-data-server-1.10.1
In the past, I would see the invisible characters after pasting the Notes section to vim/gvim. Now, I only see the "\n" characters. I just exported a contact with the persistant "\n", edited them out, and then re-imported. Maybe gnome-extra/evolution-data-server-1.10.1 text editing is fixed, but hasn't yet provided a filter for already in place "/n"? Just re-editing.. but still am scared to type "/n" into the contact I just cleaned. :-/
I've done a little more testing (without applying the patch and using e-d-s-1.10.1 and I used gvim in order to search & replace the "/n". Save the vcard to a vcf file. Open with GVim Edit > Find & Replace Find="\\n" (without quotes) Replace=" " (space without quotes -- or I may have used a double space here.) and then "Replace All" I then used teh Find & Replace to remove all unwanted " " (double spaces) and saved. Re-import the vcf (after deleting the original) and the file should have no "\n" and it should be completely safe to edit, even with "\n" because I think they're properly escaped now. Seems I had only two contacts in one folder that needed this. I'm considering myself lucky as I know this bug might impact many contacts instead of just two!
I should have saved a VCF consisting of this bug for testing & reproducing! :-/ btw, I don't know why the step for removing "double spaces" was required here, whether or not it is related to utf8/ascii and invisible characters. dunno.
I've got a very long VCF plagued with this one. Seems as if, this happens when Evolution or EDS goofs when reading in the "/n" character somehow. Maybe very long Note sections are still causing an this bug. Floating point variable defined? :-/
Copy past the text of this VCF into vim/gvim, and I see "^M" embedded into two spots of this VCF note data. More like: anymore)\^M\n\n\nBlahBlah September 30 \^M, Blah BlahBlah Keeping it simple and not saying how many bytes as this might confuse people, the "^M" is one character width and only requires one delete space to delete both the characters. This is the "invisible character(s)" I was trying to explain earlier. I'm off for coffee. I still do have a contact to test this on as the bug still now seems prevalent.
*** Bug 416664 has been marked as a duplicate of this bug. ***
gnome-extra/evolution-data-server-1.10.1-r1 Bug is still present. Did a test and simply pasting in simple text into the note section creates this bug after a certain number of characters are added to the notes section. (Only text pasted was "A-Z, a-z" Seems like a variable limitation within the code, or so many newlines characters triggers this.
Created attachment 88204 [details] test case Roger, it works for me with evolution-data-server at revision 7751 from SVN and with patch from comment #4 by Patrick. Attached vCard is based on Patrick's one, but have more new lines and in the middle also "\\n". I could save it to file and import back to evolution and it has same Note, nothing changed there.
What you're saying, the patch can be applied & compiled with evolution-data-server svn revision 7751. But, after exporting & saving the file, you get more "\\n"'s within the middle of the Notes Section? (Basically stating the patch didn't fix anything and everything seems unchanged.)
No, when you will use that attachment from comment #16, then you can see *I added* there some new lines in the middle of original vCard from Patrick. And I'm saying that, when you apply that patch on that SVN revision, and import this new vCard into evolution and export it again, then the result is new vCard file, where the Note is exactly same as that from attachment, no "\\n" added. At least for me.
Ok. Now have you tried removing all the newline strings "\n" from the notes section, saving, and reopen the contact and verify no newline character strings?
Roger, I tried it without a patch and with a patch, and *with* patch it works like expected: I re-import that my vCard, erase there *only one* "\n" in Notes section in edit dialog and none new "\n" appear there, neither in a preview nor in edit dialog after saving and reopening. Without a patch it works like you said, there are new "\n" even I saved without any in Notes. Maybe I'm wrong, but because this patch is for evolution-data-server, did you do after make && make install also evolution --force-shutdown before running evolution? It will close (already) running evolution-data-server too, so you will be sure that the new eds is running, not that old. May be you did it, but this really work for me and I don't know what I'm doing wrong.
This is a tricky bug. Almost all of my contacts as of version: =gnome-extra/evolution-data-server-1.10.1-r2 Are cleaning of the newline character bug, but the bug can be easily triggered by adding a large amount of text to the notes section. And, removing them from the notes section, closing the contact, and when the contact is reopened, more newline character strings reappear. So, from your description, you re-import the vcard and find the patch has cleaned-up most of the newline character strings, but has left one (or a couple) newline character strings. You removed the one newline character string left over, and on reopen, no more newline character strings. Have you also tried adding more text to the Notes section, closing the contact, and reopening the contact? This bug seems to be triggered by too much text within the Notes section. (I have not read the patch/code, nor have I applied it as it would take hours to recompile here, and I've gotten little response too from the list until now. I do understand eds start/stop. I'm just trying to clarify your results as your wording isn't very specific. Basically, I don't want the bug closed because it was *assumed* it was fixed, when it really wasn't.)
(Don't know if it's my brain or my keyboard at times. :-/) Almost all of my contacts are clean as of version: =gnome-extra/evolution-data-server-1.10.1-r2 Delete "Are cleaning of the newline character bug," from the above and capitalize "But".
Roger, please, it takes you hours, but we do about this for 3 days with no result. There is exactly one "\n" in Note in vCard from comment #16. I also added 5 times your whole text from comment #21 to the beginning of Note, and nothing wrong happened, none of "special" "\n" appear there. To your comment #22, that could (partially) fix other already solved bug. This one is exactly because of problem of backslash at the end of line when folding, and this patch solve it correctly. Please, try to test it, and if it will not work for you, upload here your test case with steps and exact texts what I could do to reproduce, because with that patch, everything I did, as you want, work for me.
Please commit to trunk.
Patch from comment #4 committed to trunk. Committed revision 7955.