Bug 267709 - Dolphin shows no files when dolphin's startup directory is set to same as the link you open.
Summary: Dolphin shows no files when dolphin's startup directory is set to same as the...
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 267761 267814 267970 268034 268349 268900 269703 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-03-05 14:06 UTC by Simonas
Modified: 2011-03-30 21:12 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.6.2


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simonas 2011-03-05 14:06:56 UTC
Version:           unspecified (using KDE 4.6.1) 
OS:                Linux

By default the default startup directory is /home/[youruser]/. So when you open kickoff menu, go to computer tab and click on Home folder dolphin opens but it shows zero files/folders. Then in sidebar if you click to e.g. root, and then back to home the folder opens itself correctly showing files/folders. As a temporary workaround i just set my startup location to /home/. After that when you open home folder from kickoff everything opens fine. This is a regression after updating to 4.6.1, 4.6.0 didnt have that problem.

Reproducible: Always

Steps to Reproduce:
Set dolphin startup directory to /home/[youruser] then go to kickoff, places and click on Home folder. Dolphin shows that there are no files in the directory. Altough when you open dolphin, but not home folder (e.g. with krunner you type dolphin) then home folder shows up fine. 

Actual Results:  
Dolphin shows no files/folders

Expected Results:  
It should show up Home directory correctly
Comment 1 Colin J Thomson 2011-03-05 22:28:17 UTC
I am also seeing this on Fedora 14 - 4.6.1. 
Once the Home folder is opened via kickoff or my Desktop Folder and then hitting reload it will show the files.
Comment 2 nucleo 2011-03-06 00:18:00 UTC
Confirmed for Fedora 14 and 15 Alpha.
Comment 3 Peter Penz 2011-03-06 10:00:06 UTC
*** Bug 267761 has been marked as a duplicate of this bug. ***
Comment 4 Kevin Kofler 2011-03-06 12:23:26 UTC
Looks like this is already fixed in the 4.6 branch by:
https://projects.kde.org/projects/kde/kdebase/kde-baseapps/repository/revisions/6577a4db9e42f1a1a9b319894bd00da36634e45b
which just missed the 4.6.1 tagging. :-(
Comment 5 nucleo 2011-03-06 13:56:37 UTC
I applied patch https://projects.kde.org/projects/kde/kdebase/kde-baseapps/repository/revisions/6577a4db9e42f1a1a9b319894bd00da36634e45b
to kdebase-4.6.1 but still empty home folder in Dophin.
Comment 6 Sebastian Dörner 2011-03-06 14:53:25 UTC
The problem seems to be in kdelibs. I'm currently bisecting it between 4.6.0 and 4.6.1, but that could take a while.
Comment 7 Peter Penz 2011-03-06 19:03:57 UTC
*** Bug 267814 has been marked as a duplicate of this bug. ***
Comment 8 Sebastian Dörner 2011-03-06 20:36:24 UTC
The problem was introduces with kdelibs commit bef0bd3e3ff340ad72cc757df891cbd62560f2de
http://quickgit.kde.org/?p=kdelibs.git&a=commit&h=bef0bd3e3ff340ad72cc757df891cbd62560f2de

Unfortunately I don't have much insight into this code. Might be a problem in kdelibs or dolphin needs to adapt its behaviour to the code change.
Comment 9 David Faure 2011-03-07 23:42:13 UTC
Ouch, indeed; reproduced with "dolphin $HOME". Currently investigating.
Comment 10 gabriel.gandul22 2011-03-08 03:19:40 UTC
Confirmed, I was going to report this bug but I found this one.
Thanks for the temporary fix.

The only way I was able to see the files was showing hidden files or turning on and off previews. 

This is happening in Arch with KDE SC 4.6.1.
Comment 11 David Faure 2011-03-08 11:31:09 UTC
Git commit 51707e7154082b549216b8a8ecde73505302fadc by David Faure.
Committed on 08/03/2011 at 11:23.
Pushed by dfaure into branch 'KDE/4.6'.

Fix stop() killing the list job even if another dirlister needs it.

Regression introduced by me in bef0bd3e3ff.
Symptom: "dolphin $HOME" showed up empty.

In the case of concurrent listings, I made the use of the cached items job
conditional (only created if there's anything to emit) so that we can join
the current listjob without killing it (updateDirectory) if it hasn't emitted
anything yet.
The unittest also uncovered inconsistencies in the emission of the cancelled
signal, now cacheditemsjob behaves like the listjob in this respect.

FIXED-IN: 4.6.2
BUG: 267709

M  +75   -49   kio/kio/kdirlister.cpp     
M  +5    -6    kio/kio/kdirlister_p.h     
M  +72   -1    kio/tests/kdirlistertest.cpp     
M  +1    -0    kio/tests/kdirlistertest.h     

http://commits.kde.org/kdelibs/51707e7154082b549216b8a8ecde73505302fadc
Comment 12 David Faure 2011-03-08 11:31:30 UTC
Git commit 2bef932a3b346bc5fa740280f271916f97fe1108 by David Faure.
Committed on 08/03/2011 at 11:23.
Pushed by dfaure into branch 'master'.

Fix stop() killing the list job even if another dirlister needs it.

Regression introduced by me in bef0bd3e3ff.
Symptom: "dolphin $HOME" showed up empty.

In the case of concurrent listings, I made the use of the cached items job
conditional (only created if there's anything to emit) so that we can join
the current listjob without killing it (updateDirectory) if it hasn't emitted
anything yet.
The unittest also uncovered inconsistencies in the emission of the cancelled
signal, now cacheditemsjob behaves like the listjob in this respect.

FIXED-IN: 4.6.2
BUG: 267709
(cherry picked from commit 51707e7154082b549216b8a8ecde73505302fadc)

M  +75   -49   kio/kio/kdirlister.cpp     
M  +5    -6    kio/kio/kdirlister_p.h     
M  +72   -1    kio/tests/kdirlistertest.cpp     
M  +1    -0    kio/tests/kdirlistertest.h     

http://commits.kde.org/kdelibs/2bef932a3b346bc5fa740280f271916f97fe1108
Comment 13 Peter Penz 2011-03-08 15:56:47 UTC
*** Bug 267970 has been marked as a duplicate of this bug. ***
Comment 14 Christoph Feck 2011-03-09 13:02:12 UTC
*** Bug 268034 has been marked as a duplicate of this bug. ***
Comment 15 Kai Uwe Broulik 2011-03-12 00:28:45 UTC
I don‘t know if this is related (if not, I will open an individual bug report) to this but when I tried to reproduce this bug (which affects me as well) using a different start up address (/usr for example) then dolphin just showed my home directory on startup just fine but not the set path. When using the default /home/user path then the effects described here occurred.
Comment 16 Peter Penz 2011-03-13 12:46:58 UTC
*** Bug 268349 has been marked as a duplicate of this bug. ***
Comment 17 Frank Reininghaus 2011-03-19 15:21:27 UTC
*** Bug 268900 has been marked as a duplicate of this bug. ***
Comment 18 Adrián Chaves (Gallaecio) 2011-03-20 20:59:58 UTC
@KaiUweBroulik2@hotmail.com I think it's that, and should be fixed by now.
Comment 19 johnsc301 2011-03-24 23:50:36 UTC
Kde 4.6.1 kubuntu 64bit 10.10
I am still experiencing this bug everytime.
Comment 20 Kai Uwe Broulik 2011-03-25 12:03:43 UTC
@John: This bug has been fixed for 4.6.2, you will need to wait another week to get it :)
Comment 21 Kevin Kofler 2011-03-25 12:09:47 UTC
Well, distribution packagers COULD backport the fixes…

E.g. http://pkgs.fedoraproject.org/gitweb/?p=kdelibs.git;a=commit;h=cbd3aea0346c52320e5c11fedfb42916762081c7 (committed March 8, the day of the upstream fix)…
Comment 22 Christoph Feck 2011-03-30 21:12:43 UTC
*** Bug 269703 has been marked as a duplicate of this bug. ***