Version: (using KDE KDE 3.3.0) Installed from: SuSE RPMs I use external programs to remove files and empty directories including parts of the empty trees above these directories. Earlier versions of the Konqueror tended to crash sometimes (not always), when such a removed directory tree was actually viewed. After installing Linux and the Konqueror version 3.3, it worked fine first. Removing (or adding) files was followed after short delay. Now the view isn't refreshed at all. E.g., when unpacking a file from an archive into the same directory, the file is only displayed after pushing the refresh button. Image files, when displayed in the Icon view and removed with the external program, still remain in the Konquerors view, even after clicking into other directories and back. By clicking on the icon of such a removed file, the Konqueror changes this icon to a "image file missing" icon instead of refreshing this directory. It is even worse with externally removed directory trees. Even clicking through a removed directory tree in the treeview window doesn't help, Konqueror doesn't realize that these directories (and all the files in there) aren't there any more. Even the refresh button doesn't work, when pushed on top of the tree: Konqueror simply replays all old directories. Seems that anything is frozen at the start, when the Konqueror was opened. I didn't find any other working methods to refresh, but to restart the Konqueror.
Just to get more details: Are you using famd (ps -ef|grep famd) ?
Sorry, I don't understand your question. The result of that in a bash: gerd@linux:~> ps -ef|grep famd gerd 7652 7643 0 13:42 pts/1 00:00:00 grep famd gerd@linux:~> ps PID TTY TIME CMD 7643 pts/1 00:00:00 bash 7655 pts/1 00:00:00 ps Hope you understand what that means. I don't. regards gerhard
I'm seeing this in konqueror 3.4; famd is running, the HAVE_FAM flag is set, but *no* changes to files (except for deletion/ creation) are echoed in Konqueror, opened at the folder containing the file, until refresh is pressed. I downloaded the KDE 3.4 source and explored; it seems that in kdirwatch.cpp the famd change notification is received, but is never properly propagated; it "fizzles out" at scanEntry. I made a (probably hugely ill-informed!) addition of two lines to scanEntry, but I have no idea what knock-on effects it might have as I hadn't even looked at the KDE sources until yesterday ;) For interested developers, the change was the addition of if (e->isDir) return Changed; immediately after the lines if ( (e->m_ctime != invalid_ctime) && ((stat_buf.st_ctime != e->m_ctime) || (stat_buf.st_nlink != (nlink_t) e->m_nlink)) ) { e->m_ctime = stat_buf.st_ctime; e->m_nlink = stat_buf.st_nlink; return Changed; } in method scanEntry in kdirwatch.cpp. As I said, I really don't know what I'm doing, so if there is a better way of "fixing" this, let me know :) I'm still not fully sure if this is a bug or a feature or simply a misconfiguration on my part; I seem to recall that this feature was functional in KDE 3.2.3, but I've not heard anyone else compain about it in KDE 3.4. Steps to reproduce: Ensure famd is running, and that KDE has been compiled with fam support. Open a konqueror URL at a directory to which you have write access, and which contains some dummy file you don't mind altering randomly :) Then in a separate konsole instance, cd to that directory and "touch" the file, or echo some-random-string >> into it. Observe that in the Konqueror window, the file attributes that should have changed (at least the modification time, but also size if you concatenated stuff onto it) have not changed, and will not change until the folder is manually refreshed. The desired behaviour is that the attributes in the Konqueror pane should be updated after a short pause, with no manual refresh required.
*** Bug 110434 has been marked as a duplicate of this bug. ***
This bug still persists in 3.4.3 stable, or seems to. Has anyone else noticed this?
This appears to be two separate bugs 1) As originally reported, konqueror failing to notice when files are created or deleted 2) As in SSJ's comment, Konqueror failing to notice when the attributes of an existing file change KDE 3.5.2, famd 2.7.0 linux kernel 2.6.17-1-k7 (Debian sid) I can confirm 2), but not 1)
Theo said it's valid. There's even a "patch" included. Neither of us tested the "patch".
> This appears to be two separate bugs Indeed; I actually made a bug report specifically for my own bug here: https://bugs.kde.org/show_bug.cgi?id=106394 as the symptoms are actually quite different from that in the original report (which I've never been able to reproduce) and undoubtedly have a distinct cause. This separate bug has been assigned to dmueller some months ago, but I do not know if has had a chance to look at it. Note that I have not tried my "patch" for a very long time, so it may well have suffered from bitrot and, as stated, I'm far from an expert on the internal workings of kdirwatch or konqueror, so it may have only worked originally by sheer fluke :)
Using Konqueror and/or dolphin in KDE 4 (svn trunk r827914) I've tried deleting and creating files using the command line and they immediately appear/disappear from Konqueror when they are changed, so I consider this bug as fixed in KDE 4.