opie-sync ftp URL broken for Qtopia2 connection (latest SVN)

[mkretz]

Here's the debug output the opie-sync plugin shows on the console: Attempting FTP Connection.  ftp://root:Qtopia@192.168.2.199:4242(null)/Applications/addressbook/addressbook.xml

The "(null)" is the problem: apparently the separator_path variable is not set correctly. The following (of course incorrect) patch fixes the connection for me:

@@ -284,12 +284,11 @@
     {
       fetch_pair* pair = g_list_nth_data(files_to_fetch, t);

-      ftpurl = g_strdup_printf("ftp://%s:%s@%s:%u%s%s",
+      ftpurl = g_strdup_printf("ftp://%s:%s@%s:%u/%s",
                                env->username,
                                env->password,
                                env->url,
                                env->device_port,
-                               separator_path,
                                pair->remote_filename);

       fd = fopen(pair->local_filename, "w");

[dgollub]

I guess there is maybe a better solution. At least there seems to be an undocument config option called <use_qcop>. Your problem should be fixed without any code change if you add <use_qcop>false</use_qcop> in your opie-sync config of your sync group.

I have prepared a patch which should fix your problem also when <use_qcop> is not disbabled:

Also would be interesting what qcop_get_root(qc_conn) is returning. Please create trace files of the current revision and search for

QCop root path = *????????????*

too see if the root_path request failes.

[mkretz]

Here's why qcop_get_root returns NULL:

mkretz@Epsilon3% telnet Zaurus 4243
Trying 192.168.2.12...
Connected to Zaurus.
Escape character is '^]'.
220 Qtopia 2.1.2;challenge={f3d8b6a4-1122-654c-8cf8-ddf13549ecae};loginname=root;displayname=;
USER root
331 User name ok, need password
PASS Qtopia
230 User logged in, proceed
CALL QPE/System sendHandshakeInfo()
200 Command okay
CALLB QPE/Desktop handshakeInfo(QString,bool) AAAACgAvAHIAbwBvAHQAAAAA

Apparently Qtopia returns the string as base64 encoded utf-16. See  http://josefsson.org/base-encoding/?data=AAAACgAvAHIAbwBvAHQAAAAA&mode=decode

[dgollub]

Paul, can you comment this bug? I guess this is already fixed.

[paule]

Actually it has not yet been fixed. It is quite strange - qcop_get_root() does a qcop call to QPE/Desktop handshakeInfo(QString,bool), which according to the Opie code simply returns the contents of the $HOME environment variable. I don't know how that could sometimes end up being base64 encoded (and only sometimes, since I had another user report this problem to me directly and he apparently fixed it by just resetting his device).

I had assumed some kind of corruption was going on, but I have just gone back and converted the string the other user reported, and it also appears to be a similarly encoded valid path, so I guess even though I don't understand how the situation is occurring, the opie-sync plugin should attempt to handle it if it doesn't look like a real path (probably checking if it begins with '/' would be a good enough test).

[paule]

OK, this is now fixed in SVN and I now understand a little more about what is going on. I was able to replicate the behaviour described above in Opie by simply setting the sync option in the Security settings to "Qtopia 1.7" and restarting. So of course it's nothing to do with the contents of $HOME - it's the QCop code that is formatting things as Qtopia desktop would expect it to.

Please forgive my previous ignorance :)

[dgollub]

Thanks for fixing!! If you don't mind i would assign in future opie-sync related bug reports to you. I hope you are fine with this? :)

[paule]

If you don't mind i would assign in future opie-sync related bug reports to you. I hope you are fine with this? :)

Yes, please do. Thanks.