After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 565328 - Factory prevents unmounting of device
Factory prevents unmounting of device
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: gnome-2-28
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
fixed-2-24
Depends on:
Blocks:
 
 
Reported: 2008-12-22 11:33 UTC by Mads Chr. Olesen
Modified: 2009-07-22 16:19 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
Chdir to user's home directory for the factory process (258 bytes, patch)
2008-12-22 11:36 UTC, Mads Chr. Olesen
none Details | Review
Chdir to user's home directory for the factory process (1.13 KB, patch)
2008-12-22 21:12 UTC, Mads Chr. Olesen
committed Details | Review
proposed fix (6.80 KB, patch)
2009-04-22 18:13 UTC, Christian Persch
committed Details | Review

Description Mads Chr. Olesen 2008-12-22 11:33:39 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:
Comment 1 Mads Chr. Olesen 2008-12-22 11:36:10 UTC
Created attachment 125132 [details] [review]
Chdir to user's home directory for the factory process
Comment 2 Mads Chr. Olesen 2008-12-22 21:12:17 UTC
Created attachment 125154 [details] [review]
Chdir to user's home directory for the factory process
Comment 3 Christian Persch 2008-12-24 22:37:18 UTC
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.
Comment 4 Matthias Clasen 2009-04-21 22:53:06 UTC
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
/.  


Comment 5 Behdad Esfahbod 2009-04-22 04:14:18 UTC
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 /.
Comment 6 Christian Persch 2009-04-22 18:13:24 UTC
Created attachment 133129 [details] [review]
proposed fix
Comment 7 Matthias Clasen 2009-05-04 01:55:45 UTC
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
Comment 8 Behdad Esfahbod 2009-05-04 16:53:29 UTC
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.
Comment 9 Matthias Clasen 2009-05-06 17:11:42 UTC
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... 
Comment 10 Gilles Dartiguelongue 2009-05-14 22:21:28 UTC
CCing gentoo's gnome team for tracking purpose.
https://bugs.gentoo.org/show_bug.cgi?id=269318
Comment 11 Christian Persch 2009-05-27 12:35:02 UTC
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.
Comment 12 lsof 2009-05-27 21:25:34 UTC
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.
Comment 13 Christian Persch 2009-07-22 16:19:12 UTC
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.