Re: [Tracker] [Patch] Correct locales support



Le mardi 29 aoÃt 2006 Ã 12:39 +0100, Jamie McCracken a Ãcrit :
Laurent Aguerreche wrote:


They correctly appear with 'g_async_queue_try_pop
(tracker->file_process_queue)' during process but are not indexed since:
- info->mtime == info->indextime == 0...
- action is TRACKER_ACTION_FILE_CHECK
so index_file() is not called.


this is likely a problem in the stat call - it wont find the file with a 
non-utf8 filename in those cases

The solution would be to use g_filename_from_utf8 
(http://developer.gnome.org/doc/API/2.0/glib/glib-Character-Set-Conversion.html) 
   to convert utf8 filename back to user's encoding before calling stat 
and before calling the metadata extraction stuff.

its tricky because we must avoid passing any non utf8 string to any 
other glib function

I dont have time at the moment to fix these as I am at work so patches 
welcome.

I almost finished.

Basically all calls to system (lstat, stat, g_file_test(G_FILE_EXISTS),
etc.) need to use strings in locale, not in UTF-8 in trackerd.

For clients, any sent string must be encoded in utf8.

It seems there is still some issues with tracker-extract but they should
go quickly.


But sometimes I wonder where to declare variables or why many lines are
left empty! 
Do you want to declare variables as close as their first use or at
beginning of block only?
It should be interesting to define some coding style rules and follow
them.





There is also a problem with tracker-search (and I suppose others
tools): it doesn't support non-ASCII characters in ISO-8859-1.

I set environment as before then run tracker-search in gdb. If I search
for 'ha' it terminates fine.
If I search "hÃ" it exits with code 01 and with dbus-monitor I see that
my query is not sent to trackerd!

Is DBus known to have bugs with non-UTF8 environment?

dont know?

but we should standardise on utf-8 anyhow. I guess tracker-search needs 
to check and convert to utf8 any search strings input. Obviously if we 
dont then they wont match the stuff in the DB.

Yes you're right.



Laurent.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]