Symbian s60v3 port (1/2 working?)

Ben Martin monkeyiq at
Fri Nov 16 08:34:52 GMT 2007

  I now have a port of rsync running on Symbian S60v3 (with openc/pips)
which works in both directions :) It is setup to run in daemon mode on
the phone and only allow connections from localhost, with remote access
granted through reverse ssh port forwarding or a similar VPN technology.

  For example, reading from an rsync daemon on a mobile phone with
reverse port forwarding to localhost, ie, connections to 1873 on
localhost are forwarded to 873 on the phone
rsync -av --no-owner --no-perms  rsync://localhost:1873/test1 .
will transfer the files (have not tested a recursive xfer yet though...)
similarly the transfer from the desktop machine to the mobile phone
works. The later half was much harder to achieve.
This mainly relates to getting the do_recv() function into a state that
will run and work happily with the s60v3 and openc restrictions.
Restrictions are as follows (among others);
* There is no fork(), no kill() and no exec(). A fork() followed by
exec() can be somewhat cleanly emulated with a posix_spawn call. I've
been converting fork() calls to pthread_create() with some success.
Obviously one has to modify the code in either non-error branches after
the fork() to make sure things that normally would be closed in a fork()
world remain open in a threaded world.
* There is also no pthread_kill() so trying to send a USR2 to the
pthread that is emulating the fork() not an option. The closest thing is
modifying the fork() thread to return and having the parent do a
pthread_join() instead of kill(); wait(); for child.

I'm posting here in case there is greater interest in the symbian port.
Others can have a hack on it as well ;) 
The port is based on rsync-3.0.0pre5. It will hopefully appear as a
tarball sometime soon at;
Its *extremely* rough code at the moment, but works ok for a handful of
files in both directions. There are some places where the assumptions of
fork() still exit the daemon as a whole rather than just dropping the
pthread that is used to replace the fork, but these should be fairly
easy to fix.

The intention was there at the start to make the changes somewhat clean
for easier merging, but of course this got lost along the way. many
debugging lines are still in the snapshot too. I'm not sure when/if I'll
have the time to clean this up to a mergable level :(

Also, I found that using the rename() system call can send the daemon
into lala land. So do_rename() now does a copy_file()/unlink()
combination for symbian. Nasty stuff but atleast it doesn't halt the
daemon anymore and you don't have to use --inplace when transferring to
the phone.

Also just in case I forget, getaddrinfo() is broken on openc (from what
I can tell) so I have created a very limited reimplementation of that
called xgetaddrinfo() for symbian. Perhaps the call to getaddrinfo() has
to become a do_getaddrinfo() in the general case to handle this broken
case if the sybmian build is to be merged upstream.

The rsync code allocates a bunch of fairly large char arrays on the
stack in many functions. While doing this makes memory management a lot
cleaner for C coding it also seems to indicate to symbian that you want
it to perform strange and wonderful activities which end up crashing
your application at some stage. I've tried to up the fixed stack size
for the build but can not seem to go high enough to cover all the static
buffers, maybe there is also some fixed size limit to a single stack
frame on arm4/symbian or something funky. As the replacement for fork()
uses pthreads this also makes a clean replacement for the following more
of a challenge
void foo() 
char xnamew[MAXPATHLEN];

I'm thinking perhaps some sort of nasty macro like
which can be substituted to maintain a single static buffer per
function, per thread on symbian and just do the above code on a
non-symbian build.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

More information about the rsync mailing list