GNOME Bugzilla – Bug 519071
Add write support to ObexFTP
Last modified: 2009-01-28 12:52:58 UTC
The obex-data-server can only upload local files, so we'd need to cache the files locally and then upload them (which completely breaks progress). A better way might be to: - when opening for write, create a fifo with a large buffer - pass that file onto obex-data-server, and make it sleep a bit on EAGAIN errors instead of bailing out straight away (this would need to be done in openobex' OBEX_Request, and only if it's a OBEX_CMD_PUT). It should also transform the EPIPE closing the transfer into a normal end of file.
*** Bug 526728 has been marked as a duplicate of this bug. ***
This is still the case on ubuntu Intrepid Ibex (alpha). I would like to see this fixed, especially because it used to work before hardy (when the switch to gvfs was made)
I have been using obexFs which has write support. Could bits of this not be included in the Gvfs module? http://dev.zuckschwerdt.org/openobex/wiki/ObexFs
Better yet, why can't the write operations be copied from gnome-vfs-obex? Write support worked very well back then.
I would also like to have this fixed, so I don't have to interface with obexftp directly but can simply write my code against gvfs.
*** Bug 565490 has been marked as a duplicate of this bug. ***
Created attachment 127106 [details] [review] first attempt First working patch. Works fine for files, but not for directories...I guess that's not easy, as we have no way of knowing when the directory has actually been created to cd inside it. Any opinions?
(In reply to comment #7) > Created an attachment (id=127106) [edit] > first attempt > > First working patch. Works fine for files, but not for directories...I guess > that's not easy, as we have no way of knowing when the directory has actually > been created to cd inside it. Any opinions? > Is do_push supposed to be used for directories? We already know how to create directories, but the lack of feedback from obex-data-server is a bit of a problem. Would you mind filing a bug upstream about that?
Upstream bug is http://bugs.muiline.com/view.php?id=152
Created attachment 127227 [details] [review] patch v2 Actually upstream bug doesn't really matters, as I found out the directory creation is sync. What wasn't working wrt. directories is we forgot to invalidate the query_info cache after _make_directory (), so we would get errors when we tried to lookup in the cache the newly added directory. Attached patch adds error handling and works great in my testing with trees of files and directories.
Patch looks good. Could you add a helper function to reset the directory listing cache though, and also make sure that a decent error happens when copying from non-local sources (such as smb or sftp sources)?
Created attachment 127268 [details] [review] patch v3 Factorized _invalidate_cache_helper (). When we copy from a remote location, we get "operation not supported by backend" in Nautilus, does this seems reasonable? Otherwise I can implement a fake "do_open_for_write" with a more meaningful error like "Copying files from a remote location is not supported".
(In reply to comment #12) > Created an attachment (id=127268) [edit] > patch v3 > > Factorized _invalidate_cache_helper (). > When we copy from a remote location, we get "operation not supported by > backend" in Nautilus, does this seems reasonable? Otherwise I can implement a > fake "do_open_for_write" with a more meaningful error like "Copying files from > a remote location is not supported". Don't think that'll be needed for now.
Thanks for the review, committed to trunk. 2009-01-28 Cosimo Cecchi <cosimoc@gnome.org> * daemon/gvfsbackendobexftp.c: (_invalidate_cache_helper), (do_mount), (push_transfer_started_cb), (push_transfer_completed_cb), (push_transfer_progress_cb), (push_data_free), (_push_single_file_helper), (do_push), (do_make_directory), (g_vfs_backend_obexftp_class_init): * daemon/obexftp-marshal.list: Implement write support for the ObexFTP backend (#519071).