These patches are a result of my attempts to make openobex 1.3 work with
my Sony Ericsson K300 phone, connected with an USB-to-serial adapter
(DCU-11 or so). These patches apply against the public tarball
downloaded from openobex.triq.net
This patch fixes a (IMHO) serious bug in the custom transport. If the
custom transport read an insufficient (but still nonzero) number of
bytes at a time, the read routine at lib/obex_main.c can enter a
situation in which the first instance of /* Check if we are still
connected */ consumes all the available bytes, and the second instance
sees an empty buffer, which it (incorrectly) interprets as an EOF, thus
triggering OBEX_EV_LINKERR. This bug prevents obex_test from correctly
sending or receiving objects when using the custom (serial) transport
when the custom transport fails to feed big enough chunks.
This patch fixes the setpath_client procedure of obex_test, so that the
SETPATH operation includes the don't-create flag (integer 2). The
previous value indicated creation-then-chdir of the specified path
This patch adds the filebrowsing profile GUID to the headers of the
connection request in obex_test. Without this, no useful test can be
done (at least on a Sony Ericsson K300), and file operations might even
hang the phone.
Convenience patch to send debugging to stderr, not stdout, so that it is
easier to capture to a file for later study.
This patch replaces the OBEX_CharToUnicode implementation with a more
functional version which uses iconv for charset conversion. The previous
implementation is not useful for non-English locales, because it
"converts" characters to Unicode by tacking a null byte to form a 16-bit
big-endian value. My phone has an images directory called "Imágenes"
(that is, a string with U+00E1 LATIN SMALL LETTER A WITH ACUTE). In my
case, I was lucky because the low byte of the codepoint happens to match
the same symbol in the ISO-8859-1, so some trickery with the iconv
command-line tool was enough. Now imagine somebody in Japan with a
directory name written in Kanji... Although my patch hardcodes an
assumption that the user is working in UTF-8 (with only one fallback to
ISO-8859-1), I think it is a better assumption than pure ASCII.
Please comment on these patches.
Alex Villacís Lasso
perl -e '$x = 2.4; print sprintf("%.0f + %.0f = %.0f\n", $x, $x, $x + $x);'