Bug 244163 - Dolphin doesn't refresh the folder list until I press F5
Summary: Dolphin doesn't refresh the folder list until I press F5
Status: REOPENED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.5
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords: usability
: 174733 411601 424555 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-07-10 22:00 UTC by Unknown
Modified: 2023-10-23 09:45 UTC (History)
32 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
attachment-6516-0.html (1.07 KB, text/html)
2015-10-30 15:20 UTC, ponchorat1968
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Unknown 2010-07-10 22:00:08 UTC
Version:           unspecified (using Devel) 
OS:                Linux

1. Open your Documents directory in Dolphin.
2. Now, navigate there in Konsole, too and create a simple file in there (`touch hi.txt`)
3. In Dolphin there is no sign that it noticed that the directory has changed, I have to press F5 to show that there's a new file

Reproducible: Always
Comment 1 FiNeX 2010-08-02 11:01:13 UTC
Is bug #207361 gone back?
Comment 2 FiNeX 2010-08-02 11:11:17 UTC
Anyway I cannot reproduce using KDE 4.4.5 and Linux 2.6.34.1.
Comment 3 Peter Penz 2010-11-21 10:56:18 UTC
I cannot reproduce this issue too (AFAIK David Faure and Sebastian Trüg made some related fixes recently)
Comment 4 Unknown 2010-11-26 01:24:11 UTC
It happens also in KDE 4.5.3. A moment ago it occured. I created a PDF file with OOo (with the same name just the extension varied) and Dolphin didn't refresh the list.

Sorry, but I have to reopen this.
Comment 5 Unknown 2011-02-18 00:47:49 UTC
It is in KDE 4.6.0. It affects not only Dolphin, but also the KDE file dialogue.
Comment 6 Unknown 2011-04-14 17:54:49 UTC
I can confirm it for KDE 4.6.2.

How I reproduced: I saved an attachment from KMail to a folder which had been previously opened in Dolpin. It didn't appear until I pressed F5.
Comment 7 Anıl Özbek 2011-04-29 01:47:51 UTC
I can reproduce the issue on:

Distro: Pardus 2011,
KDE: 4.6.2,
Dolphin: 1.6.1,
Kernel: 2.6.37.6


For reproduce the issue, I following these steps:

* Create a simple C++ file on Dolphin
* Open Konsole by pressing Shift + F4
* Compile (g++ foo.cpp -o foo) the code successfully
* Dolphin does not show new binary file (foo) on directory.
* Try go different directories and then return back does not change anything.
* After pressing F5, the new file appears on directory. And after pressing the F5 key once Dolphin begins to work properly and shows all new files (foo1, foo2...) on directory.


Some links that may be relevant:
* https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/479527
* http://forum.kde.org/viewtopic.php?f=66&t=84741
* http://www.pclinuxos.com/forum/index.php?topic=90054.0
Comment 8 Mahendra Tallur 2011-05-30 20:43:29 UTC
I can confirm this bug under Archlinux (all up to date), KDE 4.6.2. 

Easy way to trigger it :

1) open the "Downloads" folder under Dolphin
2) save a file with Firefox (to this very same directory)
3) witness that the file is not visible until you type F5

KDE : 4.6.2
Dolphin : 1.6.1
Kernel : 2.6.38-pae
Comment 9 Mahendra Tallur 2011-05-30 20:55:37 UTC
Oh, by the way, something very important, as others said earlier (and contrary to what my previous post lead to think) : it's pretty difficult to figure out how to reproduce the bug. Sometimes, it happens all the time, sometimes, it doesn't at all. When it does : cf. above. 

I guess it'll make it pretty difficult to iron out !
Comment 10 Guilherme Moro 2011-09-14 23:07:44 UTC
I can confirm this behavior on all KDE 4.6.x versions on Mandriva
Comment 11 Jekyll Wu 2012-01-07 11:39:23 UTC
Hmmm, this problem is tricky. 

I'm about to say "failed to reproduce" before I finally manage to make the problem happen in the last attempt . But doing it again from start fails to reproduce again and again.

I'm using KDE SC 4.8 RC2.
Comment 12 Fabrice Dejaigher 2012-02-04 07:59:46 UTC
I also encounter this problem under Kubuntu 11.10 64 bit and KDE 4.7.4

Dolphin has never been enough mature to make it the default file manager for KDE.
That's why I gona use Konqueror.
Comment 13 Jonas Nyrén 2012-02-22 13:23:27 UTC
This has been happening ever since i can remember, and it is still a problem in 4.8. As some have said above it seems to happen spuriously, but once it happens the dirwatcher seems to get stuck quite often. It mostly appears when you have a lot of activity (such as downloading something with kwooty, and sometimes when you extract larger archives), my guess something is wrong with the inotify (or whatever is being used) implementation.. so it's not really a bug that belongs in dolphin, but rather in the appropriate KDE core component.
Comment 14 Adrian Patino 2012-06-11 16:22:16 UTC
*** This bug has been confirmed by popular vote. ***
Comment 15 Zane Tu 2012-10-03 03:22:18 UTC
This bug might be a duplicate of Bug 211472 (https://bugs.kde.org/show_bug.cgi?id=211472).
Comment 16 comet.friend 2013-01-05 13:09:55 UTC
I can confirm this bug for KDE 4.8.5 in Slackware64-14.0. As said above, it usually occurs, when there's a lot of activitiy. Most reliably I can reproduce it, when I copy a lots of files (sizes from few kB up to 2.6 GB) with one Dolphin window open for my local directory and another one for the SMB share, while starting three downloads of big files from the internet.

In that scenario, when I create a new file in the local directory by editing a text file using Vim in Konsole, no icon appears in the Dolphin window, unless I close and re-open it. As opposed to what others said before, here, F5 or Shift-F5 don't always help (sometimes they do...).

Also, when I try to drag icons from the SMB share to the local directory in the other Dolphin window, seemingly nothing happens. Without the notification of the transfer in the tray, I wouldn't know, if the system responds, at all.
Comment 17 Christoph Feck 2013-01-05 20:59:36 UTC
Could you please retry with KDE 4.9.4? It could be a duplicate of bug 211472.
Comment 18 Johann Bergles 2013-01-09 08:54:55 UTC
Quite likely a problem of https://bugs.kde.org/show_bug.cgi?id=311582

If a folder got renamed during one dolphin session, dolphin does not update the contens of this directory any more.

As long as you don't rename anything, all should be fine now since V9.3

The older directory watching bug is gone.

This bug is only in dolphin, as the fileopen/save diaogs respect the changes made now.
In older times even the fileopen/save dialogs failed to update, now it is in dolphin only.

The "watching" works again if you press F5, as long as you don't rename anything again it works.
As soon as something got renamed again, it will stop updating.

Looks for me as a "cache" problem, since when you remove the "access" flag permission of  a open folder , and go back 1 directory and then go inside it again, you'll notice that you still can access this directory.

If youpress F5 then , dolphin reconize the permission change  and reports access to the folder as denied as it should be.
Comment 19 Christoph Feck 2013-01-19 21:31:37 UTC
Johann, should this bug be reassigned to Dolphin developers?
Comment 20 Johann Bergles 2013-01-23 15:38:15 UTC
(In reply to comment #19)
> Johann, should this bug be reassigned to Dolphin developers?

The bug 311582 is already assigned to the dolphin team, i don't know if this one should be assigned too.
Comment 21 Frank Reininghaus 2013-01-24 06:38:25 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > Johann, should this bug be reassigned to Dolphin developers?
> 
> The bug 311582 is already assigned to the dolphin team,

No, it's not. It's assigned to KIO because the class KDirLister from KIO is responsible for notifying us of new files/changed files/deleted files.

> i don't know if this one should be assigned too.

To be honest, I think we should better close it. I don't see any evidence here that it still happens in KDE 4.9 or later, which makes me think that it might be a duplicate of bug 211472 after all. Moreover, the later comments are clearly different from the original report, which was about a reproducible failure to update the view without any special steps required, but which happened last in KDE 4.6.2 according to the reporter.

I'm not in charge of KIO myself, but I think that the bug report in its current form is not useful for anyone:

a) Different issues mixed in one report.
b) Might be a duplicate of bug 211472.
c) No steps that make it reproducible in recent versions.

I'm not saying that view updates work perfectly. There is still at least the reproducible bug 311582, possibly more. But if you see such problems, I'd like to ask you to:

1. Check if it happens in the latest stable version (currently KDE 4.9.5), or in recent beta/RC versions or current git checkouts. The code changes all the time, in particular, some directory update issues have been fixed in KDE 4.9.4 (bug 211472). Therefore, it should be obvious that comments like "I see the bug in KDE 4.8.4" don't help us much.

2. Try hard to find steps which can be used to reproduce the problem. I know that this can be extremely difficult, but without such steps, fixing the bug is basically impossible. The fix for bug 211472 was only possible because several people worked hard to find reproducible steps and posted them in the bug report.

If you find a bug, please do report it! Figuring out what the root cause is might still not be easy (see bug 311582), but it's at least possible in principle. I don't mind if you report such bugs for Dolphin. At least I'm aware of them then before I reassign to KIO. Sometimes, I can at least do a bit of analysis before I leave the rest for David Faure's KIO magic.

Thanks for your help!
Comment 22 Frank Reininghaus 2013-01-24 06:43:09 UTC
(In reply to comment #18)
> Quite likely a problem of https://bugs.kde.org/show_bug.cgi?id=311582
> [...]
> This bug is only in dolphin, as the fileopen/save diaogs respect the changes
> made now.
> In older times even the fileopen/save dialogs failed to update, now it is in
> dolphin only.

Just to prevent that anyone says "See, it is a Dolphin bug!": I cannot confirm. If I rename in the file dialog via "context menu -> Properties", I see the very same problem.
Comment 23 Unknown 2013-01-24 09:50:31 UTC
I definitely am able to reproduce this issue in KDE 4.10 RC 2. I'm sorry to say that, but it's not fixed at all.

The steps to reproduce for me are:
1.) Open multiple folders/tabs in one window
2.) Have one folder at least 20 files inside; resize the window not to see the end of the list
3.) Copy a zip archive into that folder with multiple files inside
4.) Drag and drop only one file from Ark, from the zip file to the directory
5.) Maybe the extracted file will appear, maybe not. If not, do not close Dolphin's window. Reboot sometimes (make sure before Dolphin saves its state), do some suspends (`echo [mem|disk] > /sys/power/state`). This process may take a week or a bit more, but do not close that window and try to extract one file at a time for testing.
Comment 24 Mahendra Tallur 2013-08-18 22:56:08 UTC
Are some you guys still affected by this issue ? I haven't experienced it lately but it definitely does occur with the FolderView plasmoid in KDE 4.11.0 (Kubuntu 13.04) : what could be the common root cause ? How could I help fix this long standing bug ?

Best regards & thanks to all involved.
Comment 25 ponchorat1968 2013-10-05 15:04:17 UTC
Kubuntu 12.04LTS (64bit)
KDE 4.8.5
Dolphin 2.0 (4.8.5)

Fails to show new files when a directory is opened showing the directory tree in the file window but when you click on the directory directly, it opens and automatically shows new files.
I know this through using Arista to convert files and not seeing them in the folder that has the converted files in that is opened in its own window.
Comment 26 ponchorat1968 2013-12-03 13:43:05 UTC
Still happening in KDE/Dolphin 4.11.3
Comment 27 hypophorachus 2014-05-09 10:15:11 UTC
Fully updated Arch Linux and it's still here in version 4.13.0. How come it's not fixed in almost 4 years?
Comment 28 Christoph Feck 2014-05-09 11:19:09 UTC
Because of those who could reproduce, nobody came up with a patch? (And those, who could possibly understand the code, could not reproduce?)
Comment 29 mlebek 2014-05-15 22:24:07 UTC
Debian Wheezy, 64bit
KDE 4.8.4 
Dolphin 2.0 (4.8.4)

Reproduce:
1. open dolphin and open a folder 
2. open kwrite and save a file into same folder
3. back in same dolphin window change any filename in that folder
4. in kwrite save file with new name (save as...) in that folder

in that dolphin window doesnt appear any new files until F5
Comment 30 mlebek 2014-05-15 22:35:00 UTC
Additional for Comment 29:
i have to manually refresh this folder every time in dolphin until i deleted file(s) in dolphin in that folder.
Comment 31 GSC 2015-04-15 14:19:22 UTC
I still get this with dolphin 14.12.3 on archlinux.
Comment 32 Nikolay Stoynov 2015-05-08 21:56:04 UTC
Such long standing issue should be promoted as feature, not a bug.
Using Arch Linux
Comment 33 hypophorachus 2015-05-09 00:11:23 UTC
(In reply to Nikolay Stoynov from comment #32)
> Such long standing issue should be promoted as feature, not a bug.
> Using Arch Linux

Hah, indeed! My last comment was exactly a year ago, I use Dolphin as my main file manager since and this bug is still bugging me. Nothing's changed. Let's see what a another year may (or may not) offer.
Comment 34 David Faure 2015-05-14 22:30:08 UTC
Nothing will change until someone can find precise steps for how to reproduce the bug.

If it happens on some people's computers and not on others', then one thing to do would be checking that kdirwatch_unittest works (to catch e.g. regressions in inotify, or specific issues with some filesystems, etc.)

(This is likely a KDirWatch / inotify issue, one or two layers below KIO, two or three layers below Dolphin...)
Comment 35 ponchorat1968 2015-05-14 22:43:03 UTC
What do you mean 'precise steps'. There have been numerous people give 
detailed steps on how it happened to them, including me.
What other information do you think would be of use to help narrow it down?

When did the bug occur, which version of Kubuntu was it first noticed on.
What MoBo, CPU, RAM etc...
What extras have been added to Dolphin, if any.


On 14/05/15 23:30, David Faure wrote:
> https://bugs.kde.org/show_bug.cgi?id=244163
>
> --- Comment #34 from David Faure <faure@kde.org> ---
> Nothing will change until someone can find precise steps for how to reproduce
> the bug.
>
> If it happens on some people's computers and not on others', then one thing to
> do would be checking that kdirwatch_unittest works (to catch e.g. regressions
> in inotify, or specific issues with some filesystems, etc.)
>
> (This is likely a KDirWatch / inotify issue, one or two layers below KIO, two
> or three layers below Dolphin...)
>
Comment 36 David Faure 2015-05-14 23:18:52 UTC
Well it's not enough to say "it happened to me when doing this". If you or I can't reproduce it on another system (or even on the same system the next day), then the steps are not precise enough.

comment 23 has precise steps, but I tried that and it works here (KDE 4.14.7, kernel 3.16.7). Note that relative paths (from the .zip) are kept so the files can end up in subdirs.

comment 25 is vague, if I open a folder in the folder tree and then type "touch 1" in the embedded terminal, a file called "1" shows up as expected.

comment 29 has precise steps, but they work here as well.

In a previous bug, all this happened after renaming the folder itself. Just one example of what might be missing in all of the above, for actual reproduction of the bug.
But it could also be related to e.g. inotify limits being hit.... (i.e. check .xsession-errors for inotify or kdirwatch related errors when this happens).
Comment 37 Art 2015-08-14 04:52:00 UTC
It happens. I'm running U15.04 and I MUST press F5 to refresh (thank you whoever provided that most excellent tip!)
My Linksys WRT1900ac has a 5 TB NAS where I dump stuff from my scanner under Windows 7. However, Dolphin doesn't see the scans, EVER, after I've already opened the scans directory in Ubuntu, so I previously had to go to my Bash shell and copy stuff, because it just works!)
uname -a,
Linux hvs1 3.19.0-26-generic #27-Ubuntu SMP Tue Jul 28 18:27:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
I'm running the default window manager for Ubuntu 15.04 and everything else seems to run fine. I just don't don't like Nautilus because you have to navigate through the silly tree and I much prefer Dolphin's Windows-like address bar that dynamically switches between tree hierarchy and the free-form cut-n-paste thing that saves me using a silly tree when I can just quickly paste the address from a Vi session.

I just upgraded my old server to a reasonably fast 6-core, 16 GB server running Ubuntu, so I could volunteer to build and test fixes, on a time permitting basis, in case someone already has a proposed fix for this (I have a day job and my cat needs his nurse/slave, and I'm old, so my time and focus is at a premium).
Thx - Art
Comment 38 Alex 2015-10-30 15:07:05 UTC
For me, Dolphin 4.13.3 in Ubuntu 14.04 works.

Dolphin 14.12.3 in Ubuntu 15.04 does *not* work.

In both cases, I am using it in a different WM, i.e. outside of KDE.
Comment 39 ponchorat1968 2015-10-30 15:20:32 UTC
Created attachment 95226 [details]
attachment-6516-0.html

Don't worry, you're not on your own there. There are loads of people in
the same boat (me included).
This bug has been reported for ages and it seems nothing is being done
about it - as you are running 15.04 and the bug is STILL present.
------------------------------------------------------------------------
On 30/10/15 15:07, Alex via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=244163
>
> --- Comment #38 from Alex <a.t.page@gmail.com> ---
> For me, Dolphin 4.13.3 in Ubuntu 14.04 works.
>
> Dolphin 14.12.3 in Ubuntu 15.04 does *not* work.
>
> In both cases, I am using it in a different WM, i.e. outside of KDE.
>
Comment 40 Teoti Kalki Nathaniel 2016-07-31 10:44:24 UTC
Hey all. I'm a Gnome user who can't stand the Gnome file manager and have been using Dolphin full-time for years, even though I had to install hundreds of megs of KDE dependencies for it (which is annoying; I'd really like to see the true Linux philosophy embraced and have 'File Manager' be a modular component of ANY window manager... I truly love custom integrations, I just don't think that they should be straightjackets).
ANYWAYS. I found this thread because I have the same issue with Dolphin. It usually comes up with qBittorrent putting files into its 'completed' directory and those files not being visible in Dolphin.

For reference, I'm using the latest Debian Jessie with both Gnome and KDE installed; Dolphin was installed via apt and is whatever version the Debian repositories give me (not sure how to check its version number); I operate mostly in Gnome when I'm not in terminals; Dolphin has been my exclusive file manager since approximately day 2 of Gnome use (iirc it was the 'tooltip' that appeared at the bottom with the file name and size when you selected a file that drove me away... it covered the name of the last file in any directory (with more than a few files) and effectively rendered it 'inaccessible'. This feature could NOT be disabled. Aside from that it just looks/feels like it's the 'adolescent' file manager to Dolphin's 'undergraduate'... simplistic and almost childish?.
Comment 41 mlebek 2016-09-10 07:47:10 UTC
The chance for this bug to happen raises if you have opened  a network connection in another dolphin window, for example via sftp,  and with increasing time dolphin runs.
Probably even if there was heavy harddisk activity or cpu load sometime ago.
Comment 42 Podagric 2021-05-14 16:58:01 UTC
I tried almost all the ways to reproduce this bug mentioned and this bug did not happen. does anyone still have this happening?
Comment 43 Emil 2021-05-14 18:45:12 UTC
Yes, still happens. (I think) it was gone for years, but recently it's happening again. Dolphin Version 21.04.0.
Comment 44 postix 2021-11-24 13:47:01 UTC
*** Bug 174733 has been marked as a duplicate of this bug. ***
Comment 45 postix 2021-11-24 13:51:00 UTC
*** Bug 424555 has been marked as a duplicate of this bug. ***
Comment 46 postix 2021-11-24 13:52:37 UTC
*** Bug 411601 has been marked as a duplicate of this bug. ***
Comment 47 postix 2021-11-24 14:13:08 UTC
Bug #387663 sounds like a duplicate to me.
Comment 48 Bug Janitor Service 2023-10-15 15:53:10 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1446
Comment 49 Méven 2023-10-23 08:55:55 UTC
Git commit 0036695057dbf174b6fba46837036c986aa42d90 by Méven Car.
Committed on 22/10/2023 at 12:50.
Pushed by dfaure into branch 'master'.

KFileItem: add exists() function and use it in KCoreDirLister

Until now processPendingUpdates did not remove files.
It relied on subsequent updates to the parent dir to remove it.
But this is racy, when a file is touched its parent is added to pendingDirectoryUpdates, but if a file is removed as its parent dir is updated, no further updateDirectory will be called, and the file removal get unnoticed.

Since we already did a stat to check for file attribute changes, we can also make sure in processPendingUpdates whether a file was removed and act accordingly.

M  +26   -0    autotests/kfileitemtest.cpp
M  +1    -0    autotests/kfileitemtest.h
M  +12   -3    src/core/kcoredirlister.cpp
M  +11   -0    src/core/kcoredirlister_p.h
M  +18   -0    src/core/kfileitem.cpp
M  +7    -0    src/core/kfileitem.h

https://invent.kde.org/frameworks/kio/-/commit/0036695057dbf174b6fba46837036c986aa42d90