Post Intrepid. Can't open Home folder

[Zaki Manian]

Since the Intrepid update, the Home command fails. I can open other Files/Folder like Desktop. I can get a nautilus window that titled "Starting Home" that then closes. No errors in the Do terminal output.

[DavidGN (davidgn)]

Confirmed. I can open 'Computer' and sub-folders in home, but not 'Home'.

I thought this had been reported weeks ago - can't find it now though.

[ces (goodmorning-no)]

I can also confirm this. I thought it was a problem with nautilus at first, but opening other locations work fine. Is there a workaround? I find that I use the Home command more often than I thought.

[Heri Suhaeri (hsuhaeri)]

Also mine, i am upgrade to interpid and when open home folder go directly to Rhythmbox

[David Siegel (djsiegel-deactivatedaccount)]

I experienced this behavior once, but then the home folder opened as usual. I am fairly certain that this is not a Do bug, as the Home item is backed by a launcher file, and it is indexed and executed in the same fashion as any other launcher file; also, Nautilus clearly tries to open the folder (displays "Starting Home"), so it really appears to be more of a Nautilus issue than a Do issue.

[ces (goodmorning-no)]

Opening Home from the Places menu and other locations work fine, though; it's only from Do that I can't open it. How exactly is the Home command executed? Also, I don't know if it's relevant, but when I run nautilus without arguments from the terminal, nothing happens. Isn't it supposed to open a default location?

[ces (goodmorning-no)]

Hm, what do you know, on a hunch I ran apt-get update and upgrade, and something (I'm not sure what) from the Ubuntu Proposed Updates repository fixed it. Now the nautilus command launches the Home folder and the Do Home command opens the home folder as well :)

For what it's worth, these are the packages I upgraded, don't know what caused the change though:

Upgraded the following packages:
capplets-data (1:2.24.0.1-0ubuntu7) to 1:2.24.0.1-0ubuntu7.1
command-not-found (0.2.26ubuntu1) to 0.2.26ubuntu1.1
command-not-found-data (0.2.26ubuntu1) to 0.2.26ubuntu1.1
compiz (1:0.7.8-0ubuntu4) to 1:0.7.8-0ubuntu4.1
compiz-core (1:0.7.8-0ubuntu4) to 1:0.7.8-0ubuntu4.1
compiz-gnome (1:0.7.8-0ubuntu4) to 1:0.7.8-0ubuntu4.1
compiz-plugins (1:0.7.8-0ubuntu4) to 1:0.7.8-0ubuntu4.1
compiz-wrapper (1:0.7.8-0ubuntu4) to 1:0.7.8-0ubuntu4.1
gnome-control-center (1:2.24.0.1-0ubuntu7) to 1:2.24.0.1-0ubuntu7.1
libdecoration0 (1:0.7.8-0ubuntu4) to 1:0.7.8-0ubuntu4.1
libgnome-window-settings1 (1:2.24.0.1-0ubuntu7) to 1:2.24.0.1-0ubuntu7.1
libtotem-plparser12 (2.24.1-0ubuntu2) to 2.24.2-0ubuntu1
totem (2.24.2-0ubuntu4) to 2.24.3-0ubuntu1
totem-common (2.24.2-0ubuntu4) to 2.24.3-0ubuntu1
totem-gstreamer (2.24.2-0ubuntu4) to 2.24.3-0ubuntu1
totem-mozilla (2.24.2-0ubuntu4) to 2.24.3-0ubuntu1
totem-plugins (2.24.2-0ubuntu4) to 2.24.3-0ubuntu1

[DavidGN (davidgn)]

No change here with those updates installed.

[RedStarLabs.org (redstarlabs)]

Updating there packages:

capplets-data (1:2.24.0.1-0ubuntu7) to 1:2.24.0.1-0ubuntu7.1
gnome-control-center (1:2.24.0.1-0ubuntu7) to 1:2.24.0.1-0ubuntu7.1
libgnome-window-settings1 (1:2.24.0.1-0ubuntu7) to 1:2.24.0.1-0ubuntu7.1

from the intrepid-proposed repository fixed this bug for me.

[Thomas Koster (tkoster)]

These upgrades from intrepid-proposed do NOT fix this bug for me.

[ces (goodmorning-no)]

Hm, it seems I spoke too soon. I don't know if something changed within the system or in the recent updates, but today the Home command stopped working again :(

[RedStarLabs.org (redstarlabs)]

Same as ces!!!
It started working properly *right after* the upgrade, and during that hole session, but stopped working after reboot.

[Michael White (mikewhite314)]

The command for the File Browser menu item is

nautilus --no-desktop --browser %u

My guess is that gnome-do runs exactly that, rather than substituting one's username for %u. If you change %u to . (the current directory) then it works.

nautilus --no-desktop --browser .

[Thomas Koster (tkoster)]

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

[Jason Smith (jassmith)]

This bug has to do with Do racng *something* to start up with GNOME. Usually it can be resolved with a sleep wrapper script, but in general should be resolved in a more appropriate manner. Restarting Do after login will also resolve the issue.

[Rafael Barbosa (rrbarbosa)]

While there is no solution for the bug, what I did was to enable the Files and Folders plugin. Then to open my home folder I type in my user name, this way nautilus open /home/MyUserName. I think it is better than restart gnome-do...

[Florian M. (flomar)]

Thanks Rafael, thats a convenient workaround! To complete this, i type my username until /home/username shows up, then hit TAB and assign the alias "home" to this Do action.

[David Siegel (djsiegel-deactivatedaccount)]

It seems that the Home Folder launcher cannot execute properly if its parent process is started too early on in your session. Starting Do after your session has started appears to fix this problem, so this is not a Do bug. We may try to prevent this quirky behavior by adding an artificial delay to our session startup.

[Lee Jarratt (lee.jarratt-deactivatedaccount)]

Has anything been done on this yet? The problem persists even when using Ubuntu Jaunty Alpha 5. It's really starting to itch me now.

Other folders open, just not the Home folder so I think it is a bug related to Ubuntu. I don't know.

[Jon Arnold (jonarnoldsemail)]

Doesn't this have more to do with who owns the process than when it is started? The system owns the process when it is started with the system, and the user owns the process when it is started manually. To me, that seems like why it would get confused in opening the home folder. Surely, there's a way to debug the output somehow.

Please don't add a delay to start-up.... Ugh.

[Patrick (veinor)]

For reference, running 'nautilus' doesn't work, but 'nautilus .' does.

[Wadelius (wadelius)]

A quick fix for this bug is to dissable the "start at startup"-feature in the Gnome Do settings, and then add Gnome Do to the programs started by the system. There is an app called "Startup Applications" in settings on Ubuntu where you easily can add Gnome Do.

This fixes all the issues from the too early start for me, when I click the nautilus icon in Docky the my home folder opens.

[Wadelius (wadelius)]

By the way, I'm on Jaunty

[JoE (joehillen)]

Wouldn't the fix be to add a delay to the command when Do adds itself to the startup sessions?

i.e. adding "sleep 10 && gnome-do" rather than just "gnome-do"

[JoE (joehillen)]

Nevermind, it appears that the only way to do this is to create a bash script that will delay Do, and even then it will create another bash session which add (although only slightly) to overhead.

This is really a problem with gnome-session for not having the option to change the order of startup apps or being able to delay them. There are lots of bug reports on the subject. Here is an example. https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/148605

It might be possible to add an artificial delay to Do and create an option for it in the preferences menu, but I wouldn't know how to do that.

[Alex Launi (alexlauni)]

/usr/bin/gnome-do is a launch script, just add a sleep statement near the
top.

--
--Alex Launi

[JoE (joehillen)]

An interesting discovery that may be the key to solving this bug.

If you enter the "Open" Action, hit [TAB], and type "~" or any other folder location, it will open. Even when the "Home Folder" Action will not work.

BTW, this is in r1197, if that is relevant.

[Alex Launi (alexlauni)]

right, we already know what's causing this, but it's not our bug. it's a
gnome-session bug.

--
--Alex Launi

[Gorgonilla (lviggiani)]

@Alex:
Well but this doesn't help users at all.... :(
Can you suggest any work-around?

[Alex Launi (alexlauni)]

There are work arounds in this bug report already.

[Gorgonilla (lviggiani)]

Does adding a sleep statement to "/usr/bin/gnome-do" launching script actually work?
How many seconds?
Thank you very much.

[Alex Launi (alexlauni)]

Shouldn't need many, just try different values until it's as low as it goes
and it works, start with 10 maybe

--
--Alex Launi

[Wadelius (wadelius)]

Have you tried to dissable "start at startup" in Gnome do and making the system start it instead? That works for me on Jaunty.

I have not tried to add a sleep statement, but for it to work we need to know if gnome do inherits the faulty environment variables from the launch script or if it gets new ones because of the sleep statement.

[Gorgonilla (lviggiani)]

Hi, thanks for the suggestion.
In which way do you mean "making the system start it instead"?

[Wadelius (wadelius)]

You can add "gnome-do" to "Startup Applications" that is available in System -> Preferences. Hopefully Gnome Do will start late enough to get all the correct environmental variables.

Good luck!

[Gorgonilla (lviggiani)]

That was what I already tried before and does not work for me...
Thanks anyway!

[jhaiduce (jhaiduce)]

That doesn't work because the "start at startup" checkbox in gnome-do creates an item in "Startup Applications"...there's no functional difference between the two approaches.

[Gorgonilla (lviggiani)]

Hi Guys,
looking at the explanations given for this bug I found out that it is caused by the env variable $HOME not yet set when gnome-do starts.
However I tried playing a little bit and I discovered that this is not actually true...

If you place the following script at the beginning of /usr/bin/gnome-do:

xmessage $HOME

And rester your system, you'll see a message box showing your path to home folder. This proves that when gnome-do is started up (even at login), the env variable $HOME has already being properly set.

[Alex Launi (alexlauni)]

I'm not sure that $HOME is the variable in question, DBO can you remember
which one we figured out it was in our debugging?

--
-- Alex Launi

[Gorgonilla (lviggiani)]

well because is we can figure out which env variable is not yet set we can add a while loop at the beginning of the launching script in order to wait for this variable to be set.
I tried with

while [ -z "$HOME" ]; do
 echo "waiting"> /dev/null
done

...or...

while [ "$HOME" = "" ]; do
 echo "waiting"> /dev/null
done

But it does not work as $HOME is already set.

[Alex Launi (alexlauni)]

That only works if $HOME is the variable we're looking to be set, and I
don't think that it is. I think it was something else, but I don't know as
I've never experienced this bug. DBO knows, we worked on this not long ago.

--
--Alex Launi

[Gorgonilla (lviggiani)]

Yes, I know.
The idea is to use a similar script as the one I posted before on the missing env variable...once you will remember which one is it.. :)

[Jason Smith (jassmith)]

We never did figure out which one it was. That was the whole weirdness.
The entire env looks solid, but still something isn't getting registered
right.

On Wed, 2009-06-03 at 14:08 +0000, Alex Launi wrote:
> I'm not sure that $HOME is the variable in question, DBO can you remember
> which one we figured out it was in our debugging?
>
> --
> -- Alex Launi
>

[Raúl Núñez de Arenas Coronado (dervishd)]

Confirmed on Jaunty. I haven't tried to add the sleep command at the start of the /usr/bin/gnome-do script because it will be overriden as soon as it is updated.

Has anybody reported this in gnome-session?

[Ryan Lerch (ryanlerch)]

I am also hitting this one on Fedora 11 with gnome-do version gnome-do-0.8.1.3-5.fc11

and,

and the following workaround worked fine for me.

1. Created a script called gnome-do-start, and set it to executable (contents of the script follow:)
----------------------------------
#!/bin/bash
sleep 0.1s
gnome-do
----------------------------------

2. Went to "System > Preferences > Startup Applications"
3. Found the gnome-do entry, and Clicked the "Edit" button
4. Browsed for my gnome-do-start script, and changed the "Command" field to that value.

DONE.

hope this helps,
ryanlerch

[David Siegel (djsiegel-deactivatedaccount)]

This does not affect a default Karmic install, so this bug does not qualify for inclusion in hundredpapercuts.

However, the core of this problem could be considered a paper cut -- does this inability to open the Home Folder entry occur elsewhere? If you can find this behavior elsewhere and file a bug that specifically addresses it, that could qualify as a paper cut. However, seeing as this behavior is only made apparent when using GNOME Do, this bug is not a paper cut.

[Jason Smith (jassmith)]

Not even close to a paper cut... this is more like a bad virus, hard to detect, hard to track down, and seemingly damn near impossible to cure...

[Jan Nekvasil (jan-nekvasil)]

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.

[Jan Nekvasil (jan-nekvasil)]

AND THE SOLUTION IS: .

Yes, exactly one whitespace and one dot.

That one whitespace and one dot which belongs to /usr/share/applications/nautilus-home.desktop, right after "Exec=nautilus --no-desktop", so it will become "Exec=nautilus --no-desktop .". See the difference?

I figured it out just few minutes ago. Don't ask my why, but it works and saves us from all these mysterious troubles.

I think this should be deffinitelly reported as a Nautilus bug. Stop the rotary press, change headlines, GNOME Do is innocent! Hurray!

By the way, Michael White was on the right way in: https://bugs.launchpad.net/do/+bug/290136/comments/12

[Mike Basinger (mike.basinger)]

@jan That fixed it, you rock.

[David Siegel (djsiegel-deactivatedaccount)]

Awesome, Jan! Go tell Nautilus.

[seakayone (seakayone)]

"Yes, exactly one whitespace and one dot."

That has done the trick for me as well. Thanks.

[Alexander Hunziker (alex-hunziker)]

It turns out the bug is not in GNOME Do

[Tank (dan1990)]

Unfortunately, this bug also affects the final release of Karmic Koala. The same fix applies though.

[Hendy Irawan (ceefour)]

Confirmed the workaround by Jan #48 works 100% of the time! :-) So happy!

[Busby (mobusby)]

For a single command fix that persists forever and doesn't require super user privileges, use this command:

cat /usr/share/applications/nautilus-home.desktop | perl -pe 's/Exec=nautilus --no-desktop/Exec=nautilus --no-desktop ./g;' > $HOME/.local/share/applications/nautilus-home.desktop

This will basically create a corrected version of the faulty launcher in your home directory which will override the system's launcher.

[Anonym25712 (anonym25712)]

> This does not affect a default Karmic install, so this bug does not qualify for inclusion in hundredpapercuts.

It does. I installed a fresh Karmic last week on my computer and was still facing this bug.

Thanks Busby for the nice trick.

[Tim (tim-barlotta)]

>> This does not affect a default Karmic install, so this bug does not qualify for inclusion in hundredpapercuts.
>
>It does. I installed a fresh Karmic last week on my computer and was still facing this bug.

While it affects Karmic, it does not affect a _default_ Karmic install. Gnome-do is not installed by default. I believe that is why it was rejected by hundredpapercuts.

[Umang Varma (umang)]

Sorry if I'm missing something here. But if this bug is simply a space and a dot, then what is stopping it from being fixed? Why can't the default file just have the extra " ." ? Whether it is a papercut or not, it's not that hard to fix is it?

[ArTaX (marco-zannoni)]

I confirm that this bug affects Karmic and it is very annoying...
After startup Do doesn't open home folder, i I close it and reopen works correctly...

[CydeSwype (ircone)]

can someone link to the bug in nautilus or wherever this is supposedly being fixed? the average user definitely assumes this is a DO issue and they have no way to lobby support for a fix or to monitor status of the fix. this often happens in launchpad that an interested user wants to see if a bug has been reported or how close a fix is but the upstream location of that bug and its status are hard to find. too much digging and bugs just linger for forever. we're on karmic now and still no fix for something that appears rather trivial/quick to fix.

[ethanay (ethan-y-us)]

thank you Jan and Busby!

[Tim Hamilton (pseudomorph)]

Thanks for input into this from all involved.

One last launcher I use that I'd like to fix is the one Do uses when it launches Nautilus as 'File Manager'?

I've tried replicating Busby's launcher creator for the other launchers found in /usr/share/applications/ - that is for 'nautilus-browser.desktop', 'nautilus-computer.desktop' and 'nautilus.desktop' but none of these seem to allow me to open 'File Manager' before restarting Do. Have I missed one somewhere?

[Gama Franco (gama-franco)]

Yep, this is still happening in 10.4 beta 2

[Alexandre COLLIGNON (alexandre-collignon)]

Still happening in 10.4 LTS

[daqron (daqron)]

Confirmed in 10.04 LTS. Typing "home" causes lots of hard drive activity and the waiting mouse indicator for about 20 seconds, then ... nothing happens.

Typing "~" instead of "home" seems to work (so far). ArTaX is correct that killing and restarting gnome-do also fixes the problem. Accordingly, my workaround for this (and other gnome-do issues) is to assign the <Super>+space key binding to a perl script that kills and restarts gnome-do every time I call it.

As a general observation, it is these little annoying bugs that accumulate workarounds which kill Ubuntu's viability as a mainstream OS. I love Gnome-Do, and I love Ubuntu, but I find myself cursing OSS every time one of these bugs manifests and then fails to be addressed in a timely fashion (i.e., faster than 1.5 years). I know that isn't necessarily helpful here, but if Ubuntu is going to be marketed as "easier to use," these little things -- like being able to quickly open your home directory -- have to be taken seriously.

[Jordan Bradley (jordan-w-bradley)]

Also confirming on 10.04. the "add a ." fix works.

[Babar (babarhaq)]

Should have been fixed by now.Very sad.

[Raúl Núñez de Arenas Coronado (dervishd)]

Yes, more than a year. And yes, it happens in my freshly installed 10.04.

[Diego Xirinachs (fishbone.beat)]

Solution from comment #48 worked like a charm! thanks, also I can confirm this fix works on archlinux as well.

[Aanjhan Ranganathan (aanjhan)]

It happens in my 10.10 as well.

[Gama Franco (gama-franco)]

and in 11.04

[reeboker (reeboker-cz)]

same thing on and on and on as I see, just type "~" that should solve the problem until "Home" starts working