New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation error in iCalendar: A calendar object on a CalDAV server MUST NOT have a METHOD property. #502

Closed
flart opened this Issue Sep 13, 2016 · 30 comments

Comments

Projects
None yet
3 participants
@flart

flart commented Sep 13, 2016

Hello everyone,

I used vdirsyncer for a while now but unfortunatelly I recognized differences between the two calenders vdirsyncer shoud syncronize in the past few days. So I started the syncronization manually with -vdebug option and stumbled upon the above mentioned error.
When I tried to delete the errorness calender item, the error is caused by another calender item.
Furthermore I tried to sync both calender server against the filesystem. In this case the sync process runs without any errors.

I don't know if the METHOD:PUBLISH key in the item vdirsyncer tries to store on the SabreDAV server comes from the davmail server or the exchange server behind davmail but why it doesn't matter when syncing to filesystem?

Thanks in advance for any ideas how to solve this problem.

Yours sincerely
flart

  • Your vdirsyncer version :
  • 0.12.1
  • If applicable, which server software (and which version) you're using:
  • SabreDAV 3.2.0
  • davmail 4.7.2
  • Your Python version
  • Python 3.5.2
  • Your operating system
  • ArchARM
  • Your config file
[general]

# A folder where vdirsyncer can store some metadata about each pair.
status_path = ~/.vdirsyncer/status/

# CALDAV
[pair ralf_calendar]
a = ralf_calendar_local
b = ralf_calendar_remote


# Synchronize all collections available on "side B" (in this case the server).
# You need to run `vdirsyncer discover` if new calendars/addressbooks are added
# on the server.
# Omitting this parameter implies that the given path and URL in the
# corresponding `[storage <name>]` blocks are already directly pointing to a
# collection each.
collections = [["KalenderRalf", "KalenderRalf", "calendar"]]

# To resolve a conflict the following values are possible:
#   `null` - abort when collisions occur (default)
#   `"a wins"` - assume a's items to be more up-to-date
#   `"b wins"` - assume b's items to be more up-to-date
conflict_resolution = "b wins"

[storage ralf_calendar_local]
type = caldav
verify_fingerprint = "****"
verify=false
url = https://ratte/SabreDAV/groupwareserver.php/calendars/ralf/KalenderRalf/
username = ******
password = ******
auth = guess
useragent = "vdirsyncer"



[storage ralf_calendar_remote]
type = caldav
url = http://ratte:1080/users/******/calendar/
username = ******
password = ******
  • Use vdirsyncer -vdebug for debug output.
[...]
Doing conflict resolution for item 040000008200E00074C5B7101A82E00800000000B0A0A55B5C66D0010000000000000000100000000256A7A71FA2B34FA3A251FF1B194388...
...ralf_calendar_remote/calendar wins.
Copying (updating) item 040000008200E00074C5B7101A82E00800000000B0A0A55B5C66D0010000000000000000100000000256A7A71FA2B34FA3A251FF1B194388 to ralf_calendar_local/KalenderRalf
debug: Already normalized: '/SabreDAV/groupwareserver.php/calendars/ralf/KalenderRalf/040000008200E00074C5B7101A82E00800000000B0A0A55B5C66D0010000000000000000100000000256A7A71FA2B34FA3A251FF1B194388.ics'
debug: PUT https://ratte/SabreDAV/groupwareserver.php/calendars/ralf/KalenderRalf/040000008200E00074C5B7101A82E00800000000B0A0A55B5C66D0010000000000000000100000000256A7A71FA2B34FA3A251FF1B194388.ics
debug: {'Content-Type': 'text/calendar', 'User-Agent': 'vdirsyncer', 'If-Match': '"95f58f7da9c2e4145bd07361bb8fe8da"'}
debug: b'BEGIN:VCALENDAR\nMETHOD:PUBLISH\nPRODID:Microsoft Exchange Server 2010\nVERSION:2.0\nBEGIN:VTIMEZONE\nTZID:Europe/Berlin\nBEGIN:STANDARD\nDTSTART:16010101T030000\nTZOFFSETFROM:+0200\nTZOFFSETTO:+0100\nRRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10\nEND:STANDARD\nBEGIN:DAYLIGHT\nDTSTART:16010101T020000\nTZOFFSETFROM:+0100\nTZOFFSETTO:+0200\nRRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3\nEND:DAYLIGHT\nEND:VTIMEZONE\nBEGIN:VEVENT\nORGANIZER;CN=

[...]

\nSUMMARY;LANGUAGE=de-DE:Besprechung Abschiedsgeschenk Bine\nDTSTART;TZID="Europe/Berlin":20150325T100000\nDTEND;TZID="Europe/Berlin":20150325T103000\nUID:040000008200E00074C5B7101A82E00800000000B0A0A55B5C66D00100000000000000001\n 00000000256A7A71FA2B34FA3A251FF1B194388\nCLASS:PUBLIC\nPRIORITY:5\nDTSTAMP:20150324T170005Z\nTRANSP:OPAQUE\nSTATUS:CONFIRMED\nSEQUENCE:0\nLOCATION;LANGUAGE=de-DE:302\nX-MICROSOFT-CDO-APPT-SEQUENCE:0\nX-MICROSOFT-CDO-OWNERAPPTID:0\nX-MICROSOFT-CDO-BUSYSTATUS:BUSY\nX-MICROSOFT-CDO-INTENDEDSTATUS:BUSY\nX-MICROSOFT-CDO-ALLDAYEVENT:FALSE\nX-MICROSOFT-CDO-IMPORTANCE:1\nX-MICROSOFT-CDO-INSTTYPE:0\nX-MICROSOFT-DISALLOW-COUNTER:FALSE\nATTENDEE;

[...]

\nLAST-MODIFIED:20160105T220724Z\nEND:VEVENT\nEND:VCALENDAR\n'
debug: Sending request...
debug: 415
debug: {'Date': 'Tue, 13 Sep 2016 19:47:04 GMT', 'Server': 'nginx/1.10.1', 'X-Powered-By': 'PHP/7.0.8', 'Connection': 'keep-alive', 'Content-Type': 'application/xml; charset=utf-8', 'X-Sabre-Version': '3.2.0', 'Transfer-Encoding': 'chunked'}
debug: b'<?xml version="1.0" encoding="utf-8"?>\n<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">\n  <s:sabredav-version>3.2.0</s:sabredav-version>\n  <s:exception>Sabre\\DAV\\Exception\\UnsupportedMediaType</s:exception>\n  <s:message>Validation error in iCalendar: A calendar object on a CalDAV server MUST NOT have a METHOD property.</s:message>\n</d:error>\n'
error: Unknown error occured for ralf_calendar/KalenderRalf: 415 Client Error: Unsupported Media Type for url: https://ratte/SabreDAV/groupwareserver.php/calendars/ralf/KalenderRalf/040000008200E00074C5B7101A82E00800000000B0A0A55B5C66D0010000000000000000100000000256A7A71FA2B34FA3A251FF1B194388.ics
error: Use `-vdebug` to see the full traceback.
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/vdirsyncer/cli/tasks.py", line 66, in sync_collection
debug:     force_delete=force_delete
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/vdirsyncer/sync.py", line 228, in sync
debug:     action(a_info, b_info, conflict_resolution)
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/vdirsyncer/sync.py", line 338, in inner
debug:     _action_update(ident, b, a)(a, b, conflict_resolution)
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/vdirsyncer/sync.py", line 275, in inner
debug:     dest_meta['etag'])
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/vdirsyncer/storage/base.py", line 17, in inner
debug:     return f(self, *args, **kwargs)
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/vdirsyncer/storage/base.py", line 17, in inner
debug:     return f(self, *args, **kwargs)
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/vdirsyncer/storage/dav.py", line 498, in update
debug:     href, etag = self._put(self._normalize_href(href), item, etag)
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/vdirsyncer/storage/dav.py", line 474, in _put
debug:     headers=headers
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/vdirsyncer/storage/dav.py", line 333, in request
debug:     return utils.http.request(method, url, session=self._session, **more)
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/vdirsyncer/utils/http.py", line 74, in request
debug:     r.raise_for_status()
debug:   File "/home/ralf/.local/venvs/vdirsyncer/lib/python3.5/site-packages/requests/models.py", line 862, in raise_for_status
debug:     raise HTTPError(http_error_msg, response=self)
error: 2 out of 4 tasks failed.
@untitaker

This comment has been minimized.

Member

untitaker commented Sep 13, 2016

I don't know if the METHOD:PUBLISH key in the item vdirsyncer tries to store on the SabreDAV server comes from the davmail server or the exchange server behind davmail but why it doesn't matter when syncing to filesystem?

SabreDAV is extremely strict with regards to those methods, filesystem storage accepts almost everything.

@evert can you help us out here? There's a iCalendar exposed by DavMail that contains METHOD:PUBLISH, and @flart configured vdirsyncer to synchronize the entire calendar 1:1 to SabreDAV. Is there a possibility SabreDAV could just ignore this property? I've seen it very often from DavMail.

@evert

This comment has been minimized.

evert commented Sep 13, 2016

Hi @untitaker ,

It is fixable, BUT: I think it's better if vdirsyncer tries to ensure to it only sends valid data to a server. It is wrong to set the METHOD: property as it has a specific meaning in iCalendar.

If you don't see a way to fix this client-side, another option might be to report the error to DavMail. I'm very much a proponent of trying to fix bugs where they originate, instead of trying to create workaround for other people's mistakes ;) If you don't see a way to fix this easily in vdirsyncer, and DavMail is not fixing or acknowledging this bug, we can add a 'fixer' on the sabre/vobject side.

Some more details about this topic here:

http://sabre.io/blog/2016/validation-changes/

Basically, by default sabre/dav runs in a mode where it will try to automatically fix broken data. We don't have fixers for everything, such as this, but adding one would be fairly easy.

After a fixer is added, sabre/dav will automatically repair the file before storing it, and not send back an etag.

@untitaker

This comment has been minimized.

Member

untitaker commented Sep 13, 2016

If you don't see a way to fix this client-side, another option might be to report the error to DavMail

I've tried that once and they didn't respond at all: https://sourceforge.net/p/davmail/bugs/598/

A fixer sounds good. Maybe I should add something like that to vdirsyncer as well.

@evert

This comment has been minimized.

evert commented Sep 14, 2016

yea i really think that, even if we can do something on our side, the correct thing for you to do would actually be to reject invalid iCalendar or also fix it yourself. Being strict is good for everyone. I'm asked to create a workaround because you're not strict because davmail is not strict ;)

@evert

This comment has been minimized.

evert commented Sep 14, 2016

Of course I could also not be strict, but then the next client who comes along might be strict and break based on what the server sends it :P

@flart

This comment has been minimized.

flart commented Sep 21, 2016

OK, I understand your point of view and advocate being strict to.
But how can the problem be solved for the user?

Would it be possible for vdirsyncer to ignore such a wrong property or treat that issue as a warning instead of an error and to continue the syncronisation process with the other calendar entries?

I also would like to report that issue to davmail but unfortunatelly I don't know how to point out the problem correcly.

@untitaker

This comment has been minimized.

Member

untitaker commented Sep 22, 2016

Here's something that I'd like you to try: if you sync DavMail to filesystem
storage and then delete the lines that start with METHOD, does this really sync
back the changes, or will DavMail always reinsert the METHOD property?

Based on that we could add it to the repair command instead of doing the
fixup on-the-fly (which is much riskier in my eyes).

On Wed, Sep 21, 2016 at 01:25:03PM -0700, flart wrote:

OK, I understand your point of view and advocate being strict to.
But how can the problem be solved for the user?

Would it be possible for vdirsyncer to ignore such a wrong property or treat that issue as a warning instead of an error and to continue the syncronisation process with the other calendar entries?

I also would like to report that issue to davmail but unfortunatelly I don't know how to point out the problem correcly.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#502 (comment)

@flart

This comment has been minimized.

flart commented Sep 22, 2016

I tried this for one element and after deleting the METHOD property on the local file storage vdirsyncer reported
Copying (updating) item 040000008200E00074C5B7101A82E00800000000D0CD710C34DCD1010000000000000000100000007FF631E4167B6D4B94B755EA83A28DF6 to ralf_calendar_remote/calendar without an error. I did a second sync and there was no update to the element on the local file storage. It seems to me like DavMail accepts this change.

@untitaker

This comment has been minimized.

Member

untitaker commented Sep 22, 2016

Does the event appear broken or not at all in other Exchange clients (web interface, no idea what's out there)

On 22 September 2016 22:38:42 CEST, flart notifications@github.com wrote:

I tried this for one element and after deleting the METHOD property on
the local file storage vdirsyncer reported
Copying (updating) item 040000008200E00074C5B7101A82E00800000000D0CD710C34DCD1010000000000000000100000007FF631E4167B6D4B94B755EA83A28DF6 to ralf_calendar_remote/calendar without an error. I did a second
sync and there was no update to the element on the local file storage.
It seems to me like DavMail accepts this change.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#502 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@flart

This comment has been minimized.

flart commented Sep 23, 2016

That modified event is still ok in OWA and Outlook. A little bit too ok perhaps.
I think there is no change on that event at the exchange server at all.
When I did a sync to a different local directory and opened the above mentioned ics-file it has the method property again.
Therefor I'm not sure if davmail really syncs that event back to the exchange server or simply ignores the update from vdirsyncer.

@untitaker

This comment has been minimized.

Member

untitaker commented Sep 24, 2016

If you delete the items file for the first directory, I suspect that vdirsyncer will say that there is indeed a difference between those two items, and will report a sync conflict accordingly (provided that you didn't set conflict_resolution).

When I grep the sourcecode of DavMail, it appears that this property may have been added by Exchange, but DavMail has extra code to insert that property if it is missing: https://sourceforge.net/p/davmail/code/HEAD/tree/trunk/src/java/davmail/exchange/VCalendar.java#l155 I seriously wonder what is going on here. Is this code there to adapt to the requirements imposed by Exchange?

Anyway I've filed https://sourceforge.net/p/davmail/bugs/628/.

@untitaker

This comment has been minimized.

Member

untitaker commented Sep 24, 2016

By now I am starting doubt that adding a fixer in vdirsyncer would actually solve the problem since it's likely that this upload failure will pop up in other setups that don't involve vdirsyncer. I'd much rather see a fixer in SabreDAV (or sabre-vobject) for this, assuming DavMail won't fix this bug. That doesn't mean I want specifically you to do the work @evert, I totally understand why you don't want a bug filed against SabreDAV.

@untitaker

This comment has been minimized.

Member

untitaker commented Sep 24, 2016

@flart For now the best workaround I can offer you is, instead of syncing DavMail <-> SabreDAV, to sync DavMail <-> filesystem <-> SabreDAV and writing a shell script that removes all lines from your .ics files that start with METHOD:. cd into a collection/calendar directory and execute this:

sed -i 's/^METHOD\:.*//g' *.ics
@evert

This comment has been minimized.

evert commented Sep 24, 2016

For the I would say the process is:

  1. Get a link to a DavMail bug report related to this specific issue (answered or not)
  2. Open a feature request on sabre/vobject

I'm fine with having this feature if an attempt has been made to also file it at DavMail. And I can't make any guarantees in the future if we want to do something else with METHOD:PUBLISH later ;)

@untitaker

This comment has been minimized.

Member

untitaker commented Sep 24, 2016

I did file it at davmail, see above :)

On 24 September 2016 23:22:09 CEST, Evert Pot notifications@github.com wrote:

For the I would say the process is:

  1. Get a link to a DavMail bug report related to this specific issue
    (answered or not)
  2. Open a feature request on sabre/vobject

I'm fine with having this feature if an attempt has been made to also
file it at DavMail. And I can't make any guarantees in the future if we
want to do something else with METHOD:PUBLISH later ;)

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#502 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@flart

This comment has been minimized.

flart commented Oct 12, 2016

I tried the workaround you suggested above. This solves the problem with the METHOD-property. I used a sed -i '/^METHOD\:/d' *.ics to avoid empty lines in the caldav-files.

However vdirsyncer now raises another error saying:

warning: Server sent unsolicited item: /users/****/calendar/AAMkADcxODI0Mzg0LTNhZTAtNGM1ZS1iNjVkLWY3ZGFhNmQ2ZDBjZABGAAAAAABrqfWRYERFRaWjl4y2mCeqBwDqZLz56NxMT7PO-_VCxT0iAAAAAAENAADqZLz56NxMT7PO-_VCxT0iAAF-S8IGAAA%3D.EML
error: Unknown error occured for ralf_calendar/KalenderRalf: /users/****/calendar/AAMkADcxODI0Mzg0LTNhZTAtNGM1ZS1iNjVkLWY3ZGFhNmQ2ZDBjZABGAAAAAABrqfWRYERFRaWjl4y2mCeqBwDqZLz56NxMT7PO-_VCxT0iAAAAAAENAADqZLz56NxMT7PO-_VCxT0iAAF-S8IgAAA%3D.EML
error: Use `-vdebug` to see the full traceback.

If I open that file it's obvisiously a caldav-file but for what reason ever it got the file extension *.eml

BEGIN:VCALENDAR
METHOD:PUBLISH
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
[...]
END:VEVENT
END:VCALENDAR

Of course this is also a problem concerning davmail. However I'm not sure if vdirsyncer should handle this as an error and stop the whole sync process or wether it should raise an warning an continue the sync process for the other elements.

On the other hand I should find another way to access the exchange server since davmail seems to be a little bit unreliable.

Anyway thanks for your support.

@evert

This comment has been minimized.

evert commented Oct 12, 2016

Well, the spec actually does not say anything about file extensions. They could be anything, and even if it's .eml on the server, it's weird but not invalid. sabre/dav also accepts any extension (or none at all).

@untitaker

This comment has been minimized.

Member

untitaker commented Oct 13, 2016

In " supported servers" of the vdirsyncer docs there's a Windows-only tool linked that is supposed to repair your Exchange calendar. You may want to try that.

@untitaker

This comment has been minimized.

Member

untitaker commented Oct 13, 2016

Also the EML file extensions are normal for DavMail and standards conform. Vdirsyncer is not relying on that.

@flart

This comment has been minimized.

flart commented Oct 13, 2016

I just tried the CalCheck-Tool and it reported and rapaired one duplicate item.
But this reported item was not the same one which causes the error in vdirsyncer.

@flart

This comment has been minimized.

flart commented Nov 10, 2016

So the problem still remains and I made another attempt tonight.

Therfore I created a new Exchange calendar and copied a bunch of appointments to it.
Afterwards I started vdirsyncer to sync this new calendar to an empty filesystem folder.
Everything went fine with no warnings or errors.

After I removed the METHOD-property from all the *.ics files I started another sync process which also completed without any errors and uploaded all items to the server over the Davmail gateway.
I did some minor changes to one calendar item in Outlook for test purposes (modified start time of that event).
The next sync to update the filesystem gave me again lots of the following messeges:

warning: Server sent unsolicited item: /users/****/calendar/KalenderTest/AAMkADcxODI0Mzg0LTNhZTAtNGM1ZS1iNjVkLWY3ZGFhNmQ2ZDBjZABGAAAAAABrqfWRYERFRaWjl4y2mCeqBwDqZLz56NxMT7PO-_VCxT0iAAHHeZciAADqZLz56NxMT7PO-_VCxT0iAAEJyv-tAAA%3D.EML
warning: Server sent unsolicited item: /users/****/calendar/KalenderTest/AAMkADcxODI0Mzg0LTNhZTAtNGM1ZS1iNjVkLWY3ZGFhNmQ2ZDBjZABGAAAAAABrqfWRYERFRaWjl4y2mCeqBwDqZLz56NxMT7PO-_VCxT0iAAHHeZciAADqZLz56NxMT7PO-_VCxT0iAAEJyvpuAAA%3D.EML
error: Unknown error occured for ralf_calendar/KalenderRalf: /users/****/calendar/KalenderTest/AAMkADcxODI0Mzg0LTNhZTAtNGM1ZS1iNjVkLWY3ZGFhNmQ2ZDBjZABGAAAAAABrqfWRYERFRaWjl4y2mCeqBwDqZLz56NxMT7PO-_VCxT0iAAHHeZciAADqZLz56NxMT7PO-_VCxT0iAAEJyv9NAAA%3D.EML

So I'm not sure wether it is an good idea to remove the METHOD-property from the filesystem items.
The odd thing is that there seems to be no error in the exchange calendar as the today initially copied items are from the previously modified and uploaded calendar.

@untitaker

This comment has been minimized.

Member

untitaker commented Nov 12, 2016

I think I may have found an error in your initial config, could you paste the current config again?

@flart

This comment has been minimized.

flart commented Nov 13, 2016

Here you are:

# An example configuration for vdirsyncer.

# Optional parameters are commented out.
# This file doesn't document all available parameters, see
# http://vdirsyncer.readthedocs.org/ for the rest of them.

[general]
# A folder where vdirsyncer can store some metadata about each pair.
status_path = /home/ralf/.vdirsyncer/status_test/

# CALDAV
[pair ralf_calendar]
a = ralf_calendar_filesystem
b = ralf_calendar_remote


# Synchronize all collections available on "side B" (in this case the server).
# You need to run `vdirsyncer discover` if new calendars/addressbooks are added
# on the server.
# Omitting this parameter implies that the given path and URL in the
# corresponding `[storage <name>]` blocks are already directly pointing to a
# collection each.
collections = [["KalenderRalf", "KalenderRalf", "KalenderTest"]]

# To resolve a conflict the following values are possible:
#   `null` - abort when collisions occur (default)
#   `"a wins"` - assume a's items to be more up-to-date
#   `"b wins"` - assume b's items to be more up-to-date
conflict_resolution = "b wins"

[storage ralf_calendar_filesystem]
type = filesystem
path = /home/ralf/.calendars_test/
fileext = .ics

[storage ralf_calendar_remote]
type = caldav
url = http://ratte:1080/principals/users/***/
username = ***
password = ***

Thanks a lot for your patience.

@untitaker

This comment has been minimized.

Member

untitaker commented Nov 13, 2016

Okay that looks fine. Please send me an email with the (lightly censored) output of vdirsyncer -vdebug sync ralf_calendar then.

@flart

This comment has been minimized.

flart commented Nov 21, 2016

I’m sorry, but there seems to be something completely wrong with my setup.
Since you asked me for a debug log I’m trying to figure out how to reproduce the error.
Sometimes I get the warning “Server sent unsolicited item” or other warnings like “skipping identical href” both resulting in an error and sometimes I don’t get any. I got the error “Storage "ralf_calendar_remote/KalenderTest" contains multiple items with the same UID or even content.” when there was no item at all in outlook.
However, it seems to depend on the calendar entries I copied to the test calendar but until now I’m unable to figure out which ones are causing the errors.

Strange enough the calcheck tool doesn’t find anything.

@untitaker

This comment has been minimized.

Member

untitaker commented Jan 3, 2017

@flart This appears to be fixed in DavMail trunk: https://sourceforge.net/p/davmail/bugs/628/

Here are the instructions how to build from trunk: http://davmail.sourceforge.net/build.html

Would be nice if you could verify this works. I haven't been lucky with any version of DavMail because I no longer have the credentials to the only Exchange server that I could get to run with DavMail.

@flart

This comment has been minimized.

flart commented Jan 7, 2017

I managed to built the DavMail trunk and it seems to work.
A sync to local filesystem shows no METHOD-proberties in the .ics-files.

In the meantime I wrote a small script to get rid of that METHOD-properties.
The problem was that simply removing that properties by sed -i '/^METHOD:/d' *.ics causes vdirsyncer to sync each calender item again and again because there were changes on the filesystem.
So I used two folders: one with method-properties to sync with davmail and one without method-properties to sync with sabredav.
Perhaps someone will encounter similar problems so here's the code:

#!/bin/sh
cd /home/ralf
echo sync fs_r
vdirsyncer -c /home/ralf/.vdirsyncer/config_fs_r sync 

src='.calendars/fs_r/'
dst='.calendars/fs_l/'
for i in $(rsync -ric --ignore-existing --dry-run $src $dst | cut -d" " -f 2); do
   echo copy: $i
   cp $src$i $dst$i
   sed -i '/^METHOD\:/d' $dst$i
done
rsync -ric --delete --existing --ignore-existing $src $dst
diff -rc -I '^METHOD:.*$' $dst $src > .calendars/patchfile.patch
patch -p0 -i .calendars/patchfile.patch

echo sync fs_l
vdirsyncer -c /home/ralf/.vdirsyncer/config_fs_l sync

src='.calendars/fs_l/'
dst='.calendars/fs_r/'
for i in $(rsync -ric --ignore-existing --dry-run $src $dst | cut -d" " -f 2); do
   echo copy: $i
   cp $src$i $dst$i
   sed -i '/^METHOD\:/d' $dst$i
done
rsync -ric --delete --existing --ignore-existing $src $dst
diff -rc -I '^METHOD:.*$' $dst $src > .calendars/patchfile.patch
patch -p0 -i .calendars/patchfile.patch

echo sync fs_r
vdirsyncer -c /home/ralf/.vdirsyncer/config_fs_r sync
@flart

This comment has been minimized.

flart commented Jan 7, 2017

Moreover I recognized some difficulties caused by recurring events, e.g. birthdays.
Vdirsyncer is unable to send them through davmail to exchange and stops with an error.

But I need to figure out more clearly what's the problem. It seems to work if the recurring event is created in outlook and than synced but not when the event comes from sabredav.

@untitaker

This comment has been minimized.

Member

untitaker commented Jan 24, 2017

Okay, for now I'll close this since the original issue is solved.

@untitaker untitaker closed this Jan 24, 2017

@untitaker

This comment has been minimized.

Member

untitaker commented Mar 2, 2017

This now became an issue for me. Moodle now uses METHOD:PUBLISH in their iCal feed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment