GNOME Bugzilla – Bug 565328
Factory prevents unmounting of device
Last modified: 2009-07-22 16:19:12 UTC
Please describe the problem: Gnome-terminal, when first started from nautilus-open-terminal in a mounted directory, stays chdir'ed in that directory, preventing the device from being unmounted until all gnome-terminal's are closed. Steps to reproduce: 1. Go to mounted directory in nautilus without any terminals open 2. Open terminal using nautilus-open-terminal 3. Try to unmount device Actual results: The device cannot be unmounted until all terminals are closed Expected results: The device would unmount Does this happen every time? Yes Other information:
Created attachment 125132 [details] [review] Chdir to user's home directory for the factory process
Created attachment 125154 [details] [review] Chdir to user's home directory for the factory process
Thanks for the bug report and the patch! Committed to trunk and 2-24. This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
This change is causing bug reports in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=496947 From the bug: Description of problem: Somewhere between gnome-terminal-2.24.3 and gnome-terminal-2.26.1, gnome-terminal's CWD changed to / and now it seems like terminal_screen_get_current_dir is returning / when it can't chdir to the target working dir. Version-Release number of selected component (if applicable): gnome-terminal-2.26.1-1.fc11.x86_64 How reproducible: Always Steps to Reproduce: 1. Open a gnome-terminal as your normal user 2. $ su - => You get a root shell in /root 3. CTRL + SHIFT + T => you get a new tab as your normal user in / Alternatively: 1. $ cd /tmp 2. $ mkdir foo 3. $ cd foo 4. $ chmod a-x . 5. CTRL + SHIFT + T => you get a new tab as your normal user in / Expected results: Opening new tab in both of these cases should open a shell as your normal user in its $HOME. Additional info: 1. $ cd /tmp 2. $ mkdir foo 3. $ cd foo 4. don't do the « chmod a-x . » so that /tmp/foo is 755 5. CTRL + SHIFT + T => you get a new tab as your normal user in /tmp/foo, which is expected. And a later comment: I'm guessing this bug stems from the fact that F-10 gnome-terminal (2.24.x) ran with cwd=$HOME: home_dir = g_get_home_dir (); if (home_dir) g_chdir (home_dir); gtk_main (); 2.26.x changed to cwd=/, due to http://bugzilla.gnome.org/show_bug.cgi?id=565328: if (chdir ("/") < 0) g_warning ("Failed to chdir to /: %s", g_strerror (errno)); gtk_main (); Perhaps terminal_screen_launch_child should chdir() to the user's homedir before calling vte_terminal_fork_command() - then if vte_terminal_fork_command() fails to chdir(), we'll end up in $HOME instead of /.
So, we should fix this to: - Try chdir'ing to the current dir of foreground process, - If failed, try to chdir to the main child process of the terminal, - If failed, try to chdir to the home dir, - If all failed, we'll end up in /.
Created attachment 133129 [details] [review] proposed fix
Hmm, so with this patch, I get some reports of less than desirable behaviour: run a find process in one tab, press Ctrl-T while it is running => random dir in the new tab
So, given all the problems, and the fact that the heuristic does not work for the very common case of when you "su -", is it even worth trying? What's the usecase that it improves the experience? Someone running a subshell? Why should they? I can only think of running screen. But people typically don't run screen for local use anyway.
I've also received an earful from Jon McCann because the terminal launcher on his gnome-shell build now starts a terminal in ~/gnome-shell/src/, which is where he launched his shell from...
CCing gentoo's gnome team for tracking purpose. https://bugs.gentoo.org/show_bug.cgi?id=269318
I guess we could simply go back to chdir'ing to g_get_home_dir() instead of / . A variant of attachment 133129 [details] [review] has been committed to master, but appears not to fix all problems mentioned in the fedora bug.
This bug is frustrating in the following case: 1) Tab 1: find / 2) Open new tab 3) Tab 2: we get whatever directory find is currently searching through This is also dangerous: if you expect gnome-terminal to open a tab in the same dir as the existing tab, but it sometimes doesn't, you open up the potential for a user to delete something they didn't intend to.
I've changed it back to chdir() to g_get_home_dir(), and only fall back to / when that fails or home dir is NULL. I've also commented out the change to get cwd from foreground process instead of the primary child. I think that should fix all issues mentioned here and restore the behaviour of 2.24 in this regard.