Ticket #1035 (new defect)

Opened 5 years ago

Last modified 5 years ago

file-sync object-format is not deterministic

Reported by: henrik Owned by:
Priority: normal Milestone:
Component: OpenSync Version: 0.38
Severity: normal Keywords:
Cc:

Description

-r 5131

  1. Create a group with two file-sync members
  2. Put a VCARD in the first member's directory
  3. Slow-sync

The results are

  1. On kubuntu 8.04 (hardy) the second file-sync member will have a VCARD.
  2. On kubuntu 8.10 (intrepid) the second file-sync member will have an xmlformat file

In the past, I have seen only (A) on may distros, including intrepid.

According to IRC with dgollub, there is no defined/designed/expected correct format, but at least it should be consistent.

Attachments

8.04.ZIP (51.7 KB) - added by henrik 5 years ago.
Hardy
8.10.ZIP (49.3 KB) - added by henrik 5 years ago.
intrepid

Change History

Changed 5 years ago by henrik

Hardy

Changed 5 years ago by henrik

intrepid

comment:1 Changed 5 years ago by henrik

In the past, I have seen only (A) on may distros, including intrepid.

-->

In the past, I have seen only (A) on many distros, including intrepid.

comment:2 Changed 5 years ago by henrik

Using <Formats><Preferred>vcard21</Preferred> seems to consistently give a VCARD on both hardy and intrepid

comment:3 Changed 5 years ago by henrik

  • Milestone set to OpenSync 0.39

comment:4 Changed 5 years ago by dgollub

  • Status changed from new to assigned

I guess most expected behavoir would be to encapsulate the "original" format in a file "format". Looking into this now.

comment:5 Changed 5 years ago by dgollub

  • Owner dgollub deleted
  • Status changed from assigned to new
  • Milestone OpenSync 0.39 deleted

Current converter path builder doesn't know about the "orignal" format if there is a "internal common" format used.

Example:

file-sync and evo2-sync with xmlformat plugin - contacts.

Conversion path would look like: vcard30 -> xmlformat-contact -> *convert to file* -> file

The conveerter path build only has access with the current code to the current format (xmlforamt-contact) and the destination.

With additonal complexity the OSyncMappingEntryEngire or something like that could give information about the original format (vcard30). And if the last format is a "encapsulator" format and no other "prefered" foramt is selected - this orignal format should get prefered.

But this is not critical for 0.40 since there is a work around with "prefered_format" option.

Note: See TracTickets for help on using tickets.