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 592448 - GNOME Do cannot open home folder due to faulty .desktop file
GNOME Do cannot open home folder due to faulty .desktop file
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: general
2.27.x
Other Linux
: Normal trivial
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-20 11:10 UTC by Alexander Hunziker
Modified: 2011-07-21 19:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for Nautilus in file /usr/share/applications/nautilus-home.desktop (344 bytes, patch)
2009-11-04 12:25 UTC, Hendy Irawan
none Details | Review

Description Alexander Hunziker 2009-08-20 11:10:39 UTC
Since Ubuntu Intrepid, GNOME Do could not open the users home folder anymore. It was found that by changing the Exec line in /usr/share/applications/nautilus-home.desktop to

Exec=nautilus --no-desktop . (add "space dot")

the problem could be solved. Could nautilus upstream adopt that change?
Comment 1 Hendy Irawan 2009-11-04 12:20:54 UTC
I can confirm the bug exists and the solution is simple and works 100% of the time.

Original discussion here: https://bugs.edge.launchpad.net/do/+bug/290136
Comment 2 Hendy Irawan 2009-11-04 12:25:09 UTC
Created attachment 146908 [details] [review]
Patch for Nautilus in file /usr/share/applications/nautilus-home.desktop

Uploaded patch for file /usr/share/applications/nautilus-home.desktop

Please a maintainer apply this patch. Thank you :)
Comment 3 Michael Martin-Smucker 2010-06-13 20:03:44 UTC
Has this change been considered, yet?  It would be nice if someone from the Nautilus development team could comment on the issue, as this seems like a simple fix to a bug that affects a lot of Do users.
Comment 4 Marcus Carlson 2010-07-12 07:27:29 UTC
Not sure what's really the problem here. Running nautilus without arguments (or --no-desktop) opens a new window with home. Same if I run the current desktop file. Can't this be a problem of GNOME Do? Also, Docky seems to open a new file browser if I middle click the File Manager icon.
Comment 5 Hendy Irawan 2010-07-12 09:57:51 UTC
Marcus: Please see the original discussion in Launchpad, steps to reproduce the bug aren't straightforward.

https://bugs.edge.launchpad.net/do/+bug/290136

There are various discussions and workarounds and hacks provided, dating since OCTOBER 2008...! Let's not repeat those long tiring discussions here.

However, the solution to this issue is VERY straightforward: just put the " ." at the end of Nautilus launcher.

For example, these comment:
https://bugs.edge.launchpad.net/do/+bug/290136/comments/13
https://bugs.edge.launchpad.net/do/+bug/290136/comments/47

.......
dotrace-pre (5.0 KiB, text/plain; name="dotrace-pre"; charset="UTF-8")
dotrace-post (8.0 KiB, text/plain; name="dotrace-post"; charset="UTF-8")
After login, do can't open Home, but if I kill it and restart it, it
can.

I attached strace to do before and after restarting and found that it
makes almost identical calls to execve in each case:
     execve("/usr/bin/nautilus", ["nautilus", "--no-desktop"],
[...environment variables...]) = 0
The difference is in the environment variables. Nautilus is given a
slightly richer set of environment variables after the restart.
Unfortunately, it looks like the new variables are ones inherited from
the shell (lesspipe, shlvl, etc.) that ought to make no difference (I
restarted do from the terminal). All the important ones (usernames, X
auth and cookies, dbus sessions, etc.) are all identical.

I've attached outputs from strace before and after restarting do.
The command was:
    strace -v -e trace=process -f -p 12345 -o dotrace
.......
The problem lies in Nautilus, which, only being "prepared to be launched latter" (its name appears somewhere in script or so) in this early stage of starting GNOME desktop, silenty fails to start when is actually called latter with no location given (and _only_ with no location given).

This may look really mad at first sight, but I experience the same behavior before when I tried to put Nautilus as an item to the Openbox's menu. Nautilus failed to launch itselfs from the menu latter in session, only the cursor has been looking very busy for a while - which take the same ammount of time like in this case with GNOME Do's plugin.

You can easily reproduce this by replacing "exec=gnome-do" in /etc/xdg/autostart/gnome-do.desktop with e.g. "exec=nautilus /home", restart Your session, see happy Nautilus window, change the line to "exec=nautilus" only and relog again with no window beeing opened at all. $HOME variable is iniciated at this time.
.......
Comment 6 Michael Martin-Smucker 2010-09-16 15:26:56 UTC
As far as I can tell, the request for information has been answered, so I'm removing the NEEDINFO status.  I'm also setting the status to NEW because somewhere in the ~70 downstream comments, 5 duplicates, and 40 people who have clicked the "this affects me" link, I think it's safe to say this is a real issue (and it's also been established that this is a nautilus issue).

I don't want to resort to begging, but seriously, a 2-character fix was proposed more than a year ago and nothing has been done.  This is frustrating.
Comment 7 Cosimo Cecchi 2011-07-21 19:20:44 UTC
We don't ship this desktop file anymore, so this is not a problem now.