Closed Bug 324198 Opened 14 years ago Closed 13 years ago

Incorrect line endings with long UID loses SUMMARY information in Apple iCal

Categories

(Calendar :: Internal Components, defect)

defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ssitter, Assigned: mvl)

References

Details

(Keywords: dataloss)

Attachments

(2 files)

Bad line ends when exporting event with long UID

The testcase (extract from http://homepage.mac.com/macklausi/.calendars/GermanSpecials.ics) contains a long UID that is broken up on two lines that looks like:

UID:1027A63F-49CC-11D8-8833-00039386D1C2-D760EFD3-AB81-464D-990C-A41959F\r\n
 71F60\r\n

If you import the testcase into Sunbird and then export/publish to a new iCalendar file the UID looks like:

UID:\r\n
 1027A63F-49CC-11D8-8833-00039386D1C2-D760EFD3-AB81-464D-990C-A41959F71F60\r
\r\n
 \n

There are two line ends mixed up. I did not notice any problem when importing back into Sunbird but other clients might have a problem with this.

Tested with Sunbird/0.3a1+ (20060120) on Windows and Linux.
Attached file testcase with long UID
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody
(In reply to comment #0)
> UID:1027A63F-49CC-11D8-8833-00039386D1C2-D760EFD3-AB81-464D-990C-A41959F\r\n
>  71F60\r\n
> 
> If you import the testcase into Sunbird and then export/publish to a new
> iCalendar file the UID looks like:
> 
> UID:\r\n
>  1027A63F-49CC-11D8-8833-00039386D1C2-D760EFD3-AB81-464D-990C-A41959F71F60\r
> \r\n
>  \n

According to this mailing list post: http://www.softwarestudio.org/mail-archives/libical/0554.html
libical added handling to try and break lines at colon, semicolon, comma, or space characters, because Outlook apparently had problems with lines like the original UID above.

It appears to be this line:
http://lxr.mozilla.org/mozilla/source/calendar/libical/src/libical/icalparameter.c#272

libical appears to break the line at the colon since it's the only "preferred" character in that line. Bad libical.

I'm not sure how we want to handle this without allegedly busting Outlook compatibility.
(In reply to comment #3)
I was more concerned about "\r\n" being replaced with "\r\r\n \n" and if this might cause troubles. If all application can handle this I'm fine to close the bug.
\r\r\n\n is still bad.

I'm wondering if we should hack libical to NOT break at the first colon if this line is "UID:"

It seems really really hacky.

I wonder if the Outlook interop problem still exists in such quantity that we should keep the "break at these chars, not at column 70" hack?

Looking for input from others...
After some discussion and peering at RFC 2445, the real problem here is the line endings.  Exactly whether it causes dataloss is going to depend on what other clients do when they try and import it.  At this point, I'm going to assume that this is going to be problematic at least for some clients, and mark it as blocking.  

That said, nothing seems to be marked as a DUP of this, so it's not as though there's a lot of evidence to support that.  I think we need to get this off the blocker list, and the best way to do so would be by fixing it.  However, another way to do so would be to demonstrate that various widely-used clients (e.g. Outlook, iCal, gCal, yCal) are able to import it without losing data.
Flags: blocking0.3+
Hardware: PC → All
Given that we don't actually know that this is a problem that's going to effect real-life users, and the data itself would be recoverable if so, this won't block. If someone is able to find one or more of the clients listed that do choke on this, re-nominating for blocking would be reasonable.
Flags: blocking0.3+
Duplicate of this bug: 371133
http://tinyurl.com/yhwge4(In reply to comment #7)
> Given that we don't actually know that this is a problem that's going to effect
> real-life users, and the data itself would be recoverable if so, this won't
> block. If someone is able to find one or more of the clients listed that do
> choke on this, re-nominating for blocking would be reasonable.
> 

This affects iCal.app (version 2.0.4) -- see bug 371133

Flags: blocking-calendar0.5?
Summary: Bad line ends when exporting event with long UID → Incorrect line endings with long UID loses SUMMARY information in Apple iCal
I'd very much like to see this fixed.  Since the fix for this is likely in libical and won't need string changes, I'm okay to block on this for now.
Flags: blocking-calendar0.5? → blocking-calendar0.5+
libical first adds a newline, then folds. But in this case, the folding happens in between the two characters of the newline (\r and \n). If the id would have been 1 char longer, this would not have happened.
Anyway, the obvious fix is to fold before adding the last newline.
Assignee: nobody → mvl
Status: NEW → ASSIGNED
Attachment #258899 - Flags: first-review?(daniel.boelzle)
Comment on attachment 258899 [details] [diff] [review]
fold before adding newline

Taking this review from Daniel, since he's on vacation.

>Index: libical/src/libical/icalproperty.c
>===================================================================

>@@ -532,22 +535,21 @@
>+    /* We now use a function to fold the line properly every 75 characters. 
>+       That function also add the newline for us. */
Please remove the trailing space after the word "characters."


Otherwise works well, tested on mac lightning.  r=ctalbert with that nit.
Attachment #258899 - Flags: first-review?(daniel.boelzle) → first-review+
also make "add" plural
patch checked in
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Flags: blocking-calendar0.5+
You need to log in before you can comment on or make changes to this bug.