New stuff in gnome-vfs-obexftp
Recently, Bastien has been doing a bit of hacking on gnome-vfs-obexftp. The changes remove the use of the org.bluez.RFCOMM interface to hcid, instead doing SDP and createing RFCOMM sockets directly. This removes the need to run hcid with its experimental interfaces enabled. This is also good because the org.bluez.RFCOMM interface has been removed in newer releases (replaced by org.bluez.serial.Manager).
I’ve now integrated that patch and made a number of further clean ups so that we don’t need any D-Bus requests to establish the connection to the remote device. Now the only D-Bus requests being made are for device enumeration used for the “obex:///” virtual folder. Should make it easier to switch over to HAL if/when it supports scanning for Bluetooth devices.
I also had a go at fixing bug #116912. Using the memory type information provided in folder listings on Nokia phones, I’ve now got the get_volume_free_space() routine to return the free space of the appropriate memory type for the folder. While this works fine in the GNOME-VFS API, unfortunately it hasn’t improved matters in Nautilus. It seems to always request the free space for the root directory, so I still see an incorrect free space value for e.g. obex://[...]/Memory%20card/ on my phone. I’m not sure how I’ll go about fixing that.
There does appear to be some problems with some Sony phones, but I don’t have any hardware to test this. Perhaps this is something to work on in the next release if I can get some help debugging the problem.
Update: looks like I spoke too soon about Nautilus not getting the correct free space value. After restarting Nautilus again, it started showing the free space correctly, and I can copy large files to my memory card.