Ah btw: the patch needs to be applied with -l
Armin Bauer wrote:
JP Rosevear wrote:
On Wed, 2005-03-09 at 00:09 +0100, Armin Bauer wrote:
Anyhow, I think whats really happening is that Evolution wants to use the CATEGORIES as a whole single string and breaks it up in the UI itself. The \, means we are treating the categories as a single block rather a delimited list, that is valid icalendar, if a bit unusual.
So, judging from your answer, that you are not going to change this?
Not in the short term, is there a specific issue this is causing you?
I just have to change your vcard parser to make a exception in this case then. (btw: i changed your vcard parser to parser vcards, vnotes, vcalendar and generate these as well)
The second one is that when i add several tasks/events, request them via e_cal_get_changes, delete all of them and request again using e_cal_get_changes the returned GList will contain more items than delete d and the additional items look like random memory locations. I attached the code that produces this result. I took a look at the bug database and there are quite some bugs which reporting crashing etc when deleting tasks/events, so maybe this is related.
Probably unrelated, but it might help against some pilot bugs. What is the exactly version you are coding against?
ii evolution 2.0.4-0.1 The groupware suite ii evolution-data 1.0.4-0.1 evolution database backend server
entry [EMAIL PROTECTED] entry [EMAIL PROTECTED] entry [EMAIL PROTECTED] entry [EMAIL PROTECTED] entry [EMAIL PROTECTED] entry [EMAIL PROTECTED]
Note that i deleted 3 tasks (the ones with *1000-1*)
Have you looked at the .xml file on disk to see if thats being updated properly?
Yes. i attached the ics and .db files after the first sync (after i added 3 tasks) and after the second one (with the deletion). Nothing suspicious...
Well, next step would be to debug the code in the file backend (e-d-s/calendar/backends/file). It will be several days before i could get to this, but you can ping me with any questions if you want to take a crack.
Attached is patch against eds-1.0.4 to fix this bug. The bug was caused since you modified a hashtable during a call to g_hash_table_foreach. You call e_xmlhash_foreach_key during e_cal_backend_file_compute_changes. Then the callback e_cal_backend_file_compute_changes_foreach_key removes entries. This works if only 1 is removed but leads to corruption when removing several items.
See the comments on http://developer.gnome.org/doc/API/2.0/glib/glib-Hash-Tables.html#g-hash-table-foreach
The correct solution is to provide a new e_xmlhash_foreach_key_remove function where it is safe to remove a key. The attached patch does this. I suggest that you check the remaining code for similar errors.
Armin
------------------------------------------------------------------------
diff -u -r ./calendar/backends/file/e-cal-backend-file.c ../evolution-data-server-1.0.4-new/calendar/backends/file/e-cal-backend-file.c --- ./calendar/backends/file/e-cal-backend-file.c 2004-12-06 15:28:20.000000000 +0100 +++ ../evolution-data-server-1.0.4-new/calendar/backends/file/e-cal-backend-file.c 2005-03-14 00:50:49.000000000 +0100 @@ -1446,7 +1446,7 @@ EXmlHash *ehash; } ECalBackendFileComputeChangesData;
-static void +static gboolean e_cal_backend_file_compute_changes_foreach_key (const char *key, gpointer value, gpointer data) { ECalBackendFileComputeChangesData *be_data = data; @@ -1463,8 +1463,9 @@ e_cal_component_set_uid (comp, key); be_data->deletes = g_list_prepend (be_data->deletes, e_cal_component_get_as_string (comp));
- e_xmlhash_remove (be_data->ehash, key); + return TRUE; } + return FALSE; }
static ECalBackendSyncStatus @@ -1523,11 +1524,10 @@ be_data.kind = e_cal_backend_get_kind (E_CAL_BACKEND (cbfile)); be_data.deletes = NULL; be_data.ehash = ehash; - - e_xmlhash_foreach_key (ehash, (EXmlHashFunc)e_cal_backend_file_compute_changes_foreach_key, &be_data); + + e_xmlhash_foreach_key_remove (ehash, (EXmlHashRemoveFunc)e_cal_backend_file_compute_changes_foreach_key, &be_data);
*deletes = be_data.deletes; - e_xmlhash_write (ehash); e_xmlhash_destroy (ehash);
diff -u -r ./libedataserver/e-xml-hash-utils.c ../evolution-data-server-1.0.4-new/libedataserver/e-xml-hash-utils.c --- ./libedataserver/e-xml-hash-utils.c 2005-02-14 16:26:46.000000000 +0100 +++ ../evolution-data-server-1.0.4-new/libedataserver/e-xml-hash-utils.c 2005-03-14 00:36:50.000000000 +0100 @@ -237,6 +237,32 @@ g_hash_table_foreach (hash->objects, foreach_hash_func, &data); }
+typedef struct { + EXmlHashRemoveFunc func; + gpointer user_data; +} foreach_data_remove_t; + +static gboolean +foreach_hash_remove_func (gpointer key, gpointer value, gpointer user_data) +{ + foreach_data_remove_t *data = (foreach_data_remove_t *) user_data; + + return data->func ((const char *) key, (const char *) value, data->user_data); +} + +void +e_xmlhash_foreach_key_remove (EXmlHash *hash, EXmlHashRemoveFunc func, gpointer user_data) +{ + foreach_data_remove_t data; + + g_return_if_fail (hash != NULL); + g_return_if_fail (func != NULL); + + data.func = func; + data.user_data = user_data; + g_hash_table_foreach_remove (hash->objects, foreach_hash_remove_func, &data); +} + void e_xmlhash_write (EXmlHash *hash) { diff -u -r ./libedataserver/e-xml-hash-utils.h ../evolution-data-server-1.0.4-new/libedataserver/e-xml-hash-utils.h --- ./libedataserver/e-xml-hash-utils.h 2004-05-03 18:44:56.000000000 +0200 +++ ../evolution-data-server-1.0.4-new/libedataserver/e-xml-hash-utils.h 2005-03-14 00:34:40.000000000 +0100 @@ -47,6 +47,7 @@ } EXmlHashStatus;
typedef void (* EXmlHashFunc) (const char *key, const char *value, gpointer user_data); +typedef gboolean (* EXmlHashRemoveFunc) (const char *key, const char *value, gpointer user_data);
typedef struct EXmlHash EXmlHash;
@@ -65,6 +66,10 @@ EXmlHashFunc func, gpointer user_data);
+void e_xmlhash_foreach_key_remove (EXmlHash *hash, + EXmlHashRemoveFunc func, + gpointer user_data); + void e_xmlhash_write (EXmlHash *hash); void e_xmlhash_destroy (EXmlHash *hash);
signature.asc
Description: OpenPGP digital signature
