DavDroid failing to parse GEO: field



  • Stacktrace:

    E/davdroid.RemoteCollection(13879): Ignoring unparseable entity in multi-response
    E/davdroid.RemoteCollection(13879): at.bitfire.davdroid.resource.InvalidResourceException: net.fortuna.ical4j.data.ParserException: Error at line 37:Invalid long: "-3781\\"
    E/davdroid.RemoteCollection(13879):     at at.bitfire.davdroid.resource.Event.parseEntity(Event.java:131)
    E/davdroid.RemoteCollection(13879):     at at.bitfire.davdroid.resource.RemoteCollection.multiGet(RemoteCollection.java:100)
    E/davdroid.RemoteCollection(13879):     at at.bitfire.davdroid.syncadapter.SyncManager.pullNew(SyncManager.java:190)
    E/davdroid.RemoteCollection(13879):     at at.bitfire.davdroid.syncadapter.SyncManager.synchronize(SyncManager.java:87)
    E/davdroid.RemoteCollection(13879):     at at.bitfire.davdroid.syncadapter.DavSyncAdapter.onPerformSync(DavSyncAdapter.java:129)
    E/davdroid.RemoteCollection(13879):     at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:259)
    E/davdroid.RemoteCollection(13879): Caused by: net.fortuna.ical4j.data.ParserException: Error at line 37:Invalid long: "-3781\\"
    E/davdroid.RemoteCollection(13879):     at net.fortuna.ical4j.data.CalendarParserImpl.parse(CalendarParserImpl.java:148)
    E/davdroid.RemoteCollection(13879):     at net.fortuna.ical4j.data.CalendarBuilder.build(CalendarBuilder.java:210)
    E/davdroid.RemoteCollection(13879):     at net.fortuna.ical4j.data.CalendarBuilder.build(CalendarBuilder.java:191)
    E/davdroid.RemoteCollection(13879):     at net.fortuna.ical4j.data.CalendarBuilder.build(CalendarBuilder.java:179)
    E/davdroid.RemoteCollection(13879):     at at.bitfire.davdroid.resource.Event.parseEntity(Event.java:126)
    E/davdroid.RemoteCollection(13879):     ... 5 more
    

    Sample file snippit containing problem:

    mattcen@owen:tmp$ grep -n GEO event_1*
    event_177195052@meetupcom.ics:37:GEO:-37.81\\;144.96
    event_189027122@meetupcom.ics:37:GEO:-37.81\\;144.96
    

    I haven't yet taken the time to read the code to see if I can debug this further, but I suspect it's not particularly difficult to fix.


  • developer

    Could you please provide a full ICS file? Then I can report the issue to http://sourceforge.net/p/ical4j/bugs/



  • On 2014-06-18 05:24, rfc2822 wrote:

    Could you please provide a full ICS file? Then I can report the issue to http://sourceforge.net/p/ical4j/bugs/

    Sure; see attached. This file came from https://meetup.com. Thanks for
    your quick response.


    Reply to this email directly or view it on GitHub:
    https://github.com/rfc2822/davdroid/issues/268#issuecomment-46428512

    --
    Regards,
    Matthew Cengia


  • developer

    I can't see an attachment. Could you please provide a link?



  • Argh. Stupid github not showing email attachments or allowing anything to be attached except images. Here you go: https://gist.github.com/mattcen/4350a039c415cd9b45b3. The original site has the file available from the "Export" link on this page: http://www.meetup.com/Datahack-Melbourne/events/177195052/, but that's only accessible if you have an account on Meetup, and you may need to be a member of that meetup group.


  • developer

    Works here with ez-vcard/0.9.5, so this was probably updated in upstream.

    Will work with the next DAVdroid release.



  • On 2014-07-29 16:47, rfc2822 wrote:

    Works here with ez-vcard/0.9.5, so this was probably updated in upstream.

    Will work with the next DAVdroid release.

    Thanks for this. Just confirming, were you able to reproduce the bug
    before it started working?

    --
    Regards,
    Matthew Cengia


  • developer

    Oh… the problem wasn't in VCards but in iCalendars… reopened.


  • developer

    I have now confirmed the problem. The GEO field in the iCal is:

    GEO:-37.81\\;144.96
    

    According to the iCal RFC 4.8.1.6 Geographic position, the format has be specified like this (quoting the example):

    GEO:37.386013;-122.082932
    

    It seems like your iCal from Meetup has an invalid format: a latitude of "-37.81" (escaped backslash) doesn't make any sense, so iCal4j throws an exception while parsing.

    Can you report this to MeetUp?



  • Thanks for chasing this up rfc2822. I was incorrect, this isn't Meetup's fault, it's OwnCloud's. If I download my entire OwnCloud calendar as an iCal and look for a GEO: tag, it looks like this:

    GEO:-37.81;144.96

    If I access the same event via OwnCloud's CalDav service, however, it looks like this:

    GEO:-37.81\\;144.96

    I guess I should be reporting this as a bug to OwnCloud. What's interesting, however, is that when viewed on an Apple device (either iOS calendar, or iCal on my Mac), it doesn't complain. That said, I also have no evidence that it's actually parsed and understood the attribute. I still think it is more reasonable for ical4j to ignore that field than explode and hide the entire appointment, however. Do you agree? Had you reported this to ical4j? If not, I think I'll file bugs to both ical4j and OwnCloud.


  • developer

    What's interesting, however, is that when viewed on an Apple device (either iOS calendar, or iCal on my Mac), it doesn't complain. That said, I also have no evidence that it's actually parsed and understood the attribute.

    Probably, the property isn't parsed and so the client (libary) doesn't have a problem with the line, because the general syntax is OK.

    I still think it is more reasonable for ical4j to ignore that field than explode and hide the entire appointment, however. Do you agree?

    iCal4j actually supports this property, so IMO it's OK to throw an exception if it is malformed.

    By the way, I don't think that GEO:-37.81\;144.96 is correct. The syntax is

    geo        = "GEO" geoparam ":" geovalue CRLF
    geoparam   = *(";" xparam)
    geovalue   = float ";" float
    ;Latitude and Longitude components
    

    There is no TEXT element that may contain escaped characters.



  • True, but I'm still unconvinced that the correct solution is to silently ignore the entire event; it's a terribly fragile approach. There are lots of iCal implementations out there, and obviously many of them aren't perfect. I think the library should be a little more robust. Granted, though, I'm not sure how it should notify the user there was a problem. I certainly wouldn't want it throwing up an error every time it tried to read the event.


  • developer

    True, but I'm still unconvinced that the correct solution is to silently ignore the entire event; it's a terribly fragile approach.

    Please understand that DAVdroid uses libraries for iCal and VCF handling. DAVdroid either gets data from the libraries or it doesn't. So the discussion about handling of erroneous iCal files would have to go to the iCal4j forums. I understand that end users don't care, but discussing the issue here won't improve the situation.

    Granted, though, I'm not sure how it should notify the user there was a problem. I certainly wouldn't want it throwing up an error every time it tried to read the event.

    That's the problem we're constantly exposed to. Is it better to notify the user of every little mistake and break the whole thing or is it better to ignore errors, possibly resulting in unexpected behaviour or even in data loss?

    At the moment, I think that ignoring invalid data is a good approach. DAVdroid is not an iCal validator; if certain contacts or events don't work, users will notice (you did ;)). Also, I don't like settings, so implementing two ways (notify/ignore) and let the user choose (most users will choose the wrong setting and then complain) isn't such a good idea.

    I'll close this for now. If you have a good idea on how to deal with such errors, please open a new issue for that.


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.