#65 Repair non-compliant icalendar entries a day ago

Comment by ~whynothugo on ~whynothugo/vdirsyncer-rs

A relevant scenario: https://github.com/pimutils/vdirsyncer/issues/1140

The server exposes the same identical entry under different hrefs. We should be able to identify these identical copies and keep just one.

#89 Make [storage]username optional 7 days ago

Comment by ~whynothugo on ~whynothugo/vdirsyncer-rs

Дилян Палаузов referenced this ticket in commit a74012c.

REPORTED RESOLVED FIXED

#88 On download dashes are stripped from filenames 8 days ago

Comment by ~whynothugo on ~whynothugo/vdirsyncer-rs

Regarding your prior comment: vdirsyncer synchronises calendars, and our lower level primitive is calendar components (todos, events, journal entries), not files.

If two storages have different events with the same filename, there is no conflict; they are different events. If we were synchronising files, then there would be a conflict, but this is not a file synchronisation tool. Forcing users to rename files manually would introduce a problem where there is none. And we'd be gaining nothing in return.

Moreover, in some storages (e.g.: WebDav, JMAP) individual events don't have a filename.

Like I said before: I'll consider retaining filenames where possible, but I have to double check if this doesn't mess up anything else.

#88 On download dashes are stripped from filenames 8 days ago

Comment by ~whynothugo on ~whynothugo/vdirsyncer-rs

Why is RFC 6578 not used to synchronize iCalendar objects from a remote server to local storage?

Because servers may or may not support RFC6578. Synchronising without relying on RFC6578 is the most compatible option.

RFC6578 is in my radar however, and I intend to add support for it. Several of the internal design choices that I've made were done keeping in mind that RFC6578 support would be added in future.

There was no issue tracking this work, so I've created https://todo.sr.ht/~whynothugo/vdirsyncer-rs/92

#92 Support DAV:sync-collection from RFC6578 8 days ago

0:enchancement added by ~whynothugo on ~whynothugo/vdirsyncer-rs

#92 Support DAV:sync-collection from RFC6578 8 days ago

3: vstorage added by ~whynothugo on ~whynothugo/vdirsyncer-rs

#92 Support DAV:sync-collection from RFC6578 8 days ago

3: libdav added by ~whynothugo on ~whynothugo/vdirsyncer-rs

#92 Support DAV:sync-collection from RFC6578 8 days ago

Ticket created by ~whynothugo on ~whynothugo/vdirsyncer-rs

rfc6578 provides a mechanism for the server to track changes in a collection between synchronisations.

It should be used on servers where it is available.

#44 Prevent secrets from being swapped 9 days ago

Comment by ~whynothugo on ~whynothugo/vdirsyncer-rs

See also: memfd_secret(2), which is Linux-only.

#88 On download dashes are stripped from filenames 13 days ago

Comment by ~whynothugo on ~whynothugo/vdirsyncer-rs

To be honest, I don't quite recall why we use UIDs instead of the path from the server. I have a strong suspicion that there are other factors involved. I'll keep this open for now, but will take some time to think about it.

---

When synchronising, a file named a.ics may exist on both sides and describe entirely different events. In this case, we'll use a random filename for one unless they are the same event (e.g.: unless they share the same UID).

---

The paths in URLs are not necessarily filenames. E.g.: a server can report that events are stored as:

/dav/calendars/user/hugo/00fsWMCvxPHGbMWw/031sSQFuFJZXhZ8E
/dav/calendars/user/hugo/00fsWMCvxPHGbMWw/07pqbROw8tUg9xcZ
/dav/calendars/user/hugo/00fsWMCvxPHGbMWw/0BzTEecb6x69Igdj
/dav/calendars/user/hugo/00fsWMCvxPHGbMWw/0CGYH7P3bClmkf3C

The last segment is not a filename, it is merely a path, and has no extension. It often does look like a filename, but that is not mandatory (and completely outside of our control).

---

I can make fileext= optional, and use .ics for icalendar and .vcf for vcard if no value is specified.