g_spawn_async hangs if chdir to the passed working_directory hangs in the child
@egmontkob
Submitted by Egmont Koblinger Link to original bug (#772354)
Description
I'm copying lots of data to/from my Android phone's internal and external storage, using USB 2.0 (I think) and the MTP protocol.
The contents automatically appear (on Ubuntu) under /run/user/1000/gvfs.
Filesystem operations are quite slow (I don't know why), usually it takes 1-2 seconds to copy a tiny file (copying a large file doesn't take much longer though), and gets even slower if I do concurrent operations from multiple terminals. It's very easy to get to a response time of 5-10 seconds. Every once in a while it completely hangs until I unplug the phone (kernel or gfvs or android bug? - whatever). (Other setups, e.g. an NFS mount with a dead server could also easily lead to this situation.)
Most of the time this only effects what's happening inside a particular terminal tab, and that's okay. There's one exception though:
If the current working directory is on such a slow/dead virtual filesystem, opening a new gnome-terminal window or tab becomes this slow/dead too. That is, the entire UI of all the g-t windows is unresponsive and unusable for the duration.
I'm not sure what exactly goes on (haven't traced yet), I guess it's something with setting the CWD as per a previous OSC 7, but... any operation that accesses an arbitrary FS location specified by the user (even just simply cd'ing there or stat'ing it) should only happen after forking, that is, not effect the main g-t-s in any way so that it remains usable even if there are slow/dead filesystems around.