Comment 5 for bug 1713098

I don't know if the timeout is borderline short, but the unmount definitely failed. Logs further down (sorry, these logs are interleaved and have no timestamp) show that unmount failed because the filesystem was busy:
ftp: Queued new job 0x1002d932210 (GVfsJobCloseRead)
ftp: <- 0 -- 226 Transfer Complete.
ftp: send_reply(0x1002d932210), failed=0 ()
ftp: backend_dbus_handler org.gtk.vfs.Mount:Unmount (pid=7819)
ftp: g_vfs_job_unmount_new request: 0x789a5002adf0
ftp: Queued new job 0x1002d93f740 (GVfsJobUnmount)
ftp: send_reply(0x1002d93f740), failed=1 (File system is busy)
ftp: send_reply(0x1002d93f740), failed=1 (File system is busy)

That "transfer complete" was about self.do_mount_check_api(gfile, True) which, among other things, downloads "myfile.txt" and asserts its contents. That's the last thing that method does, and the "finally:\nself.unmount_api(gfile)" call comes right after that.

I don't know why there are two "file system is busy" messages in the logs. And I also don't know if it would have worked had we waited a bit more, or if the myfile.txt retrieval somehow left that file open and that's why unmount failed.