pimsync-migration.7.scd does not say anything about

conflict_resolution = "a wins" ⇔ conflict_resolution keep a

I think https://todo.sr.ht/~whynothugo/pimsync/93 is a variant of the current case.

Is this now implemented as "conflict_resolution keep a"?

pimsync-migration.7.scd contains:

• The readonly configuration directive is not yet implemented.

but 676bd90f98538fb54a94650b884753b780b6 is “Implement the read-only directive for storages”.

As read-only is per-storage and conflict_resolution per pair, for me it is not clear how these parameter relate. Is for a read-only storage conflict_resolution ignored, if it would modify the read-only storage? Which option has higher-precedence?

For the above example, https://calendar.google.com/calendar/ical/aegee.eu_v5mn651imeqpvs87v4ln7hr1f4%40group.calendar.google.com/public/basic.ics contains:

BEGIN:VEVENT
DTSTART:20250220T180000Z
DTEND:20250220T190000Z
DTSTAMP:20250214T154141Z
UID:532mrkjlno1r41spdc9vb4247o@google.com
CREATED:20250214T143308Z
DESCRIPTION:Join the info session …
LAST-MODIFIED:20250214T143308Z
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Info Session about hosting Statutory Events
TRANSP:OPAQUE
END:VEVENT

it includes also the definition for VTIMEZONE:TZID:Europe/Brussels, as there are recurring events and for these the timezone appears to be necessary.

In any case the file genereted by pimsync includes:

BEGIN:VCALENDAR
BEGIN:VEVENT
DTSTART:20250220T180000Z
DTEND:20250220T190000Z
DTSTAMP:20250214T154345Z
UID:532mrkjlno1r41spdc9vb4247o@google.com
CREATED:20250214T143308Z
DESCRIPTION:Join the info session …
LAST-MODIFIED:20250214T143308Z
SUMMARY:Info Session about hosting Statutory Events
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Brussels
…
END:VTIMEZONE
END:VCALENDAR

In this particular case there is no need to include the Timezone definition in the per-event ics file, as that file does not use the timezone definition.

Yes, it seems to fixed now.

That would produce invalid iCalendar files; if an event references a timezone, the timezone needs to be there.

No, it does not have to be there, unless it cannot be assumed that the software reading the event knows the timezone, e.g. the TZ name starts with X-. Usually, software reading VEVENT has its own TZ database, and it can be used.

In fact Cyrus IMAP stopped at https://github.com/cyrusimap/cyrus-imapd/pull/5167 including the timezone in iTIP messages.

And because in my case I do not want to have the timezone, I explicitly strip it, just like stripping SEQUENCE:0, https://mail.aegee.org/cgit/aegee-cal/tree/getaegeeevents.js#n253 .

$ pimsync sync

creates files with structure

BEGIN:VCALENDAR
BEGIN:VEVENT
DTSTART:20201010T090000Z
DTEND:20201010T150000Z
…
BEGIN:VTIMEZONE
TZID:Europe/Brussels
…
END:VTIMEZONE
END:VEVENT
END:VCALENDAR

VTIMEZONE must be outside of VEVENT.

In fact I want to have an option not to include the VTIMEZONE component.

With this configuration file

status_path "status"

storage local {
type vdir/icalendar
path "."
fileext ics
}

pair p {
storage_a remote
storage_b local
collections "from a"
}

storage remote {
type webcal
collection_id google_upstream
url "https://calendar.google.com/calendar/ical/aegee.eu_v5mn651imeqpvs87v4ln7hr1f4%40group.calendar.google.com/public/basic.ics"
}

pimsync sync

creates files with structure

BEGIN:VCALENDAR BEGIN:VEVENT DTSTART:20201010T090000Z DTEND:20201010T150000Z … BEGIN:VTIMEZONE TZID:Europe/Brussels … END:VTIMEZONE END:VEVENT END:VCALENDAR

VTIMEZONE must be outside of VEVENT.

In fact I want to have an option not to include the VTIMEZONE component.

Does this mean, that DELETE on collections fails with If: when Etag is used, but works correctly with Ctag?

With this configuration file

status_path "status" 

storage local {  
 type vdir/icalendar  
 path "."  
 fileext ics  
}  

pair p {  
 storage_a remote  
 storage_b local  
 collections "from a" 
}  

storage remote {  
 type webcal  
 collection_id A  
 url "https://calendar.google.com/calendar/ical/ aegee.eu_v5mn651imeqpvs87v4ln7hr1f4%40group.calendar.google.com/public/basic.ics"  
}

I call

pimsync sync

OK. Now I change above “collection_id A” to “collection_id B”. “RUST_BACKTRACE=full pimsync sync” prints

thread 'tokio-runtime-worker' panicked at vstorage/src/sync/status.rs:347:13:
internal error: entered unreachable code: uid missing for mapping immediately after INSERT stack backtrace:
0: 0x556a2468deda - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hddb63c9699c7309a 1: 0x556a246b3633 - core::fmt::write::hc338d61058c0d66c
2: 0x556a24689843 - std::io::Write::write_fmt::h80dab97476750852
3: 0x556a2468dd22 - std::sys::backtrace::BacktraceLock::print::h8f82e207cdd02441
4: 0x556a2468ee0c - std::panicking::default_hook::{{closure}}::hced8387e9fe5d421 5: 0x556a2468ec52 - std::panicking::default_hook::ha3f6ad90792a97b6 6: 0x556a2468f3e7 - std::panicking::rust_panic_with_hook::h061c0c1eebc4ec34 7: 0x556a2468f246 - std::panicking::begin_panic_handler::{{closure}}::h5e30b0d14d1187f1 8: 0x556a2468e3b9 - std::sys::backtrace::__rust_end_short_backtrace::h5df085eb7f7be6aa 9: 0x556a2468ef0c - rust_begin_unwind 10: 0x556a242f98d0 - core::panicking::panic_fmt::h70cef1aa03d57ac6 11: 0x556a245e6ba4 - vstorage::sync::status::StatusDatabase::get_or_add_collection::hc624b838d98b53d6 12: 0x556a24464c30 - vstorage::sync::execute::create_collection::{{closure}}::hb2b1a455f4619e6d 13: 0x556a2446606b - vstorage::sync::execute::<impl vstorage::sync::plan::Plan>::execute::{{closure}}::h1cc5a3ba4ee691e5 14: 0x556a2446f6c7 - pimsync::NamedPair::sync_once::{{closure}}::h02270639bf733ad6 15: 0x556a244705b9 - pimsync::App::sync::{{closure}}::{{closure}}::h6cfc1435647968a5 16: 0x556a244565ea - tokio::runtime::task::core::Core<T,S>::poll::he84429cb449718c2 17: 0x556a2433cebd - tokio::runtime::task::harness::Harness<T,S>::poll::h6932b75b401d3ddc 18: 0x556a24642340 - tokio::runtime::scheduler::multi_thread::worker::Context::run_task::h44253cb3d5fcd2a7 19: 0x556a2464135c - tokio::runtime::scheduler::multi_thread::worker::Context::run::hbebf61b2b4d8de73 20: 0x556a2465a2b6 - tokio::runtime::context::scoped::Scoped::set::h31f679a22081950d 21: 0x556a246494ce - tokio::runtime::context::runtime::enter_runtime::h115d10a5aa39cacb 22: 0x556a246411da - tokio::runtime::scheduler::multi_thread::worker::run::hcbfab7378d97fe3d 23: 0x556a2463ecd7 - <tokio::runtime::blocking::task::BlockingTask as core::future::future::Future>::poll::h6dcca7415493296b 24: 0x556a24650d03 - tokio::runtime::task::core::Core<T,S>::poll::he60e4ee02b482839 25: 0x556a24638bf4 - tokio::runtime::task::harness::Harness<T,S>::poll::hcf27c75870a4d7c3 26: 0x556a2463cd0b - tokio::runtime::blocking::pool::Inner::run::h96181a4b8799731f 27: 0x556a2464d05e - std::sys::backtrace::__rust_begin_short_backtrace::h18680ac1dbb71e86 28: 0x556a24655719 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hb7a637f5291e79c6 29: 0x556a24693bcb - std::sys::pal::unix::thread::Thread::new::thread_start::h5a4e1576cc88c794 30: 0x7f122f607cd7 - start_thread 31: 0x7f122f68bc8c - __GI___clone3 32: 0x0 - ERROR [pimsync] Sync task aborted: JoinError::Panic(Id(5), "internal error: entered unreachable code: uid missing for mapping immediately after INSERT", ...).

With release build, I tried now twice, the time is again 4 minutes.