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
Is bug #207361 gone back?
Anyway I cannot reproduce using KDE 4.4.5 and Linux 2.6.34.1.
I cannot reproduce this issue too (AFAIK David Faure and Sebastian Trüg made some related fixes recently)
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.
It is in KDE 4.6.0. It affects not only Dolphin, but also the KDE file dialogue.
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.
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
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
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 !
I can confirm this behavior on all KDE 4.6.x versions on Mandriva
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.
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.
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.
*** This bug has been confirmed by popular vote. ***
This bug might be a duplicate of Bug 211472 (https://bugs.kde.org/show_bug.cgi?id=211472).
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.
Could you please retry with KDE 4.9.4? It could be a duplicate of bug 211472.
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.
Johann, should this bug be reassigned to Dolphin developers?
(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.
(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!
(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.
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.
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.
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.
Still happening in KDE/Dolphin 4.11.3
Fully updated Arch Linux and it's still here in version 4.13.0. How come it's not fixed in almost 4 years?
Because of those who could reproduce, nobody came up with a patch? (And those, who could possibly understand the code, could not reproduce?)
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
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.
I still get this with dolphin 14.12.3 on archlinux.
Such long standing issue should be promoted as feature, not a bug. Using Arch Linux
(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.
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...)
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...) >
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).
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
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.
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. >
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?.
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.
I tried almost all the ways to reproduce this bug mentioned and this bug did not happen. does anyone still have this happening?
Yes, still happens. (I think) it was gone for years, but recently it's happening again. Dolphin Version 21.04.0.
*** Bug 174733 has been marked as a duplicate of this bug. ***
*** Bug 424555 has been marked as a duplicate of this bug. ***
*** Bug 411601 has been marked as a duplicate of this bug. ***
Bug #387663 sounds like a duplicate to me.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1446
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
This issue has resurfaced in Dolphin 24.02.2, KDE Frameworks 6.1.0 but only on SMB network shares (local directories don't suffer from this issue) smb4k (3.2.5) still relies on kded5 (5.115.0)