From: Daniel P. <da...@ri...> - 2006-08-04 08:09:09
|
Daniel Gollub <dg...@su...> writes: > On Sunday 30 July 2006 16:16, Daniel Pittman wrote: >> Hrm. Small problem: that includes all the contact details for people in >> my phone, some of which I can't make available to the general public. >> >> Is there any easy way to address that issue without rendering the trace >> files completely useless? > Yes. I committed today a feature to toggle the privacy level of the trace > function. This require that you update opensync to the latest revision. To > toggle the privacy level that none sensitive information leaks - use: > > export OSYNC_TRACE=/tmp/osync_trace/; > export OSYNC_PRIVACY=1; > > Please check the trace file if any private information is leaking before > sending. This is quite new and not well tested yet. Sorry for the delay. It looks like that covers the specific requirements for privacy, so please find the traces from a re-run sync between the two systems at this URL: http://rimspace.net/osync-trace-kde-nokia6680.tar.gz They were too big to send through the gmane interface that I use to read the list, and besides, not everyone needs 4MB of trace files from me. I can leave them there forever, pretty much, so go for your life. There are also a whole slew of data preservation issues between the two systems, among which are: - Symbian alarms are lost from Calendar entries - Undetected duplication of Calendar entries - "Memo" type events change to "Meeting" type events - this happened only when the duplicate was sent from KDE to the phone I believe that these are known issues, and that there isn't (currently) much to be done because the infrastructure for mapping one platform to another is in development. If that isn't correct, and there is some way that I can help by discovering and mapping the format used by the Symbian OS calendar or whatever, please let me know. I don't have a huge level of free time, but I can try and work on this because it is a pretty desirable solution for me. >> > Also interesting would be the information in which format the vcal or >> > vtodo is stored. Use the --dumpinfo paramter of the syncml-obex-client >> > if you use the syncml obex connection. [...] > So far the entries seems to be correct. I cannot imagine that the > detector was not able to detect them... so let us see if the trace > files are helping ;) Great. Well, if there is anything else that would help I am happy to do what I can. Regards, Daniel -- Digital Infrastructure Solutions -- making IT simple, stable and secure Phone: 0401 155 707 email: co...@di... http://digital-infrastructure.com.au/ |