GNOME Bugzilla – Bug 651729
don't kill the mount if g_vfs_backend_ftp_has_feature() fails
Last modified: 2014-04-22 21:52:04 UTC
Created attachment 189107 [details] [review] make g_vfs_backend_ftp_has_feature() failure non fatal Hi. So, I'm using nautilus to copy files over ftp to a crappy all-in-one multimedia box. It seems the ftp on this box advertises chmod but does not actually support it. Each time I copy a file, the connection gets killed after the copy. For now, I removed the call to g_vfs_job_failed() and just return FALSE but maybe something more clever could be used.
I have the same problem. In my case the problem consists with an ftp server that supports chmod, too. I tested your patch and it works perfect for me. I use gvfs 1.8.2 installed and compiled at an Arch Linux system. I guess, numerous have problems with copying files via nautilus over ftp, and the bug 630348 relates to the same problem. So on my opinion the priority should be high. https://bugzilla.gnome.org/show_bug.cgi?id=630348
Hi. It would be nice if one of the developers could have a look at this... thanks.
So should we pretend we run Fedora for developers to be interested in commenting this bug?
Created attachment 194897 [details] [review] Fix a crash with try_get_settable_attributes returning async on failure The solution is actually almost right, but it is a little simpler than that. The section of code should just return TRUE instead of FALSE. Returning FALSE means that the operation should be deferred in a thread (and the thread may not run in this case until the job is destroyed so it crashes.) At least in my system, marking the operation as failed doesn't disconnect the mount. It was disconnected because the backend crashed. From the backend header: These try_ calls should be fast and non-blocking, scheduling the i/o operations async (or on a thread) or reading from cache. Returning FALSE means "Can't do this now or async", which means the non-try_ version will be scheduled in a worker thread.
(In reply to comment #4) > Created an attachment (id=194897) [details] [review] > Fix a crash with try_get_settable_attributes returning async on failure > > The solution is actually almost right, but it is a little simpler than that. > The section of code should just return TRUE instead of FALSE. Returning FALSE > means that the operation should be deferred in a thread (and the thread may not > run in this case until the job is destroyed so it crashes.) At least in my > system, marking the operation as failed doesn't disconnect the mount. It was > disconnected because the backend crashed. I can confirm this solution works just fine, thanks Chris! Any chance to have this committed?
(In reply to comment #4) > Created an attachment (id=194897) [details] [review] > Fix a crash with try_get_settable_attributes returning async on failure > > The solution is actually almost right, but it is a little simpler than that. > The section of code should just return TRUE instead of FALSE. Returning FALSE > means that the operation should be deferred in a thread (and the thread may not > run in this case until the job is destroyed so it crashes.) At least in my > system, marking the operation as failed doesn't disconnect the mount. It was > disconnected because the backend crashed. You're absolutely right, thanks for spotting this! commit a94b84592163bc727ba15467d0fdf3ca7782f334 Author: Chris Wulff <crwulff@rochester.rr.com> Date: Mon Aug 29 16:08:04 2011 +0200 ftp: Fix return value of try_get_settable_attributes() on failure This fixes a crash on failed try_get_settable_attributes() call. https://bugzilla.gnome.org/show_bug.cgi?id=651729
*** Bug 654423 has been marked as a duplicate of this bug. ***