Bug 756

Hello, it's working on Fedora/RHEL build.
I guess there is a missing dependency in your build process.

Sorry, I spoke too fast.

What I have tested:

Opening 2 konqueror with "file management" profile and 1 konsole.

Actions done in Konqueror 1:
1) create a file => Konqueror 2 automatically shows it
2) delete a file => Konqueror 2 automatically removes it
3) changes permissions on file => konqueror 1 and 2 both correct permissions

Actions done in konsole:
1) create a file => both konqueror show it
2) remove a file => both konqueror remove it from display
3) chmod a file => konqueror does NOT refresh automatically
4) change the content of the file => konqueror does NOT refresh automatically

So, if I try to sum up:
1) actions done in Konqueror are correctly propagated to all konqueror instances
2) actions done outside konqueror are seen only if it is creation or deletion.

Thanks for the detailed testing, which prompted me to do likewise. :)

I think I can narrow the complaints.

Permission or ownership changes I make directly from within Konqueror appear immediately. Permission or ownership changes I make in Konsole never appear in Konqueror. That needs attention.

File additions and deletions on a local drive are updated immediately, whether performed in Konqueror or Konsole.

File additions and deletions on an NFS network share performed by the same user are seen almost immediately when performed in Konsole.

File additions and deletions on an NFS network share performed by a different user are seen almost a minute later when performed in Konsole. That needs attention.

Viewing file content changes in Konqueror are weird.

When I change the file from within Konsole I see the change immediately in Konqueror.

When I open a file in Kedit by selecting the file in Konqueror, then Konqueror never reflects the changes. To be sure the problem is not Kedit, I opened the file through Konqueror with Kwrite and Kate too. That needs attention.

File content changes I make owned by the current user on an NFS network share are seen within a few seconds. Not snappy, but within a few seconds.

Changes I make as another user on an NFS network share take up to a minute to appear. That needs attention.


Summary:

1. Konqueror never updates external permission or ownership changes.
2. Konqueror updates file additions and deletions made by other users on network shares only after an unacceptably long delay.
3. Konqueror never updates content changes to files when the file is opened through Konqueror.
4. Konqueror updates file content changes made by other users on network shares only after an unacceptably long delay.

Another tidbit:

When I create a diff file in konsole, konqueror does not update the file pane with the new file.

For example, in Konqueror select a desired directory, press F4 to open konsole, and then I type something like the following:

diff -urN kdebase kdebase.new > kdebase-new-diff.diff

Konqueror never updates. I have to manually refresh the pane.

Some more konqueror quirks in 3.5.13:

The file pane does not update when used with kdesu. I can update a file directly in konqueror and the file pane does not update. For example, when I copy a file to the same directory, the popup appears asking me for a new filename. When I choose an existing file name and affirm I want to overwrite, the file pane never updates.

Another quirk is when I use konqueror in kdesu mode, selecting a file from the file pane does not open the file in the respective app as root but as the normal user. For example, when I double-click on a text file the file opens in kwrite or kate as normal user and not as root. Sort of defeats half the idea of using konqueror through kdesu. :( I know the difference because I use a different background color in kwrite and kate to help me remember when I am working as root. Further, when kwrite or kate opens, I am unable to view root's home directory, further verifying the editors are opening as normal user and not root. ;(

An update:

I rebuilt and installed new 3.5.13 packages after inotify support was added. Unfortunately, there is no difference with this bug report.

This behavior does not cause any crashes, but is serious. Manually refreshing the pane solves these quirks, but that is not a good option in a multi user environment where files change routinely.

File management is essential to managing any computer.

Slackware 13.1 uses gamin.

BTW, I can replicate some of these problems in KDE 3.5.10 too.

I'm open to the idea that the problem is local, or PEBKAC, although there is one other person reporting some problems too. When this bug report bubbles to the top of the list, please let me know how to help troubleshoot. I won't pretend to know how TDE interfaces with the underlying file notification schemes.

Stupid question: did you set the WITH_INOTIFY flag to on when you rebuilt tdelibs?

Gee, um, now that you ask, no, I didn't. :)

In my eagerness to test today I had forgotten that yesterday when I rebuilt all of my 3.5.13 packages I could not get those related patches back ported to 3.5.13. Specifically, I could patch and build kdelibs but not kdebase. Some of the patches had changes to krandr mixed in. kdebase would not build despite downloading and trying to back port a krandr patch for kdebase.

Therefore yesterday I built kdelibs with -DWITH-DNOTIFY and had forgotten that fact today.

So ignore my last post. Insufficient data. :(

I could try to figure out why kdebase 3.5.13 wouldn't build. I'd have to post the errors to the list. Probably I am missing another patch that complements the ones I have.

Or we wait until I start building from GIT. I am waiting until all build related bug report patches are merged until focusing on building from GIT. I want to build patch free. I submitted many build build related bug reports. You've been smacking 'em down rather quickly the past several days but some remain. That's why I have been focusing on backporting to 3.5.13.

Hello, I've patched and rebuilt kdelibs 3.5.13 with inotify support.
(I've backported this patch: http://www.trinitydesktop.org/patches/1326095653:24f144faf98249012e7b1657a5dfe93750f0dfde.diff )

I've built with -DWITH_INOTIFY=ON (but is it ON by default so it should not matter).

I confirm it does NOT resolve the problem in konqueror.
I do not see any inotify-related patch for kdebase so I did not rebuilt it.

Do both inotify and dnotify need to be enabled? If inotidy is enabled should dnotify be disabled when building? Do they conflict or does inotify merely take precendence in the code when available?

Do any other packages need inotify support? For example I notice amarok has an inotify patch.

Just a thought here, because we saw similar behavior in another bug report 335 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=335). Could the problems be related to using the various list views? People using icon views see much less file information. Basically they see only an icon and the file name. Those people would not notice the failures described here.

Looks like part of this problem never was fixed in KDE 3:

http://bugs.kde.org/show_bug.cgi?id=106394

There are three "URL notifier" daemons for Trinity. Are any of those related to these problems? None of the daemons have a description (bug report 762).

Some interesting news:

I submitted some descriptions for the three "URL Notifier" daemons (bug report 762). Looks like those daemons play a role in this overall mystery. However, I already had all three enabled.

According to kdelibs/kio/kio/kdirwatch.cpp, dnotify is not used when inotify has been verified to exist.

Today I noticed when running 3.5.13 that gam_server never starts. gam_server always starts under 3.5.10. As far as I know, my rebuilt version 3.5.10 has inotify support. Perhaps, similarly to ignoring dnotify, the kdirwatch code ignores gamin when inotify is enabled, but I did not see that (I'm still learning C++ and could be overlooking that).

With my previous version of kdelibs 3.5.13, which has dnotify support but not inotify, gam_server did not start there either.

I figured out how to backport the -DWITH_INOTIFY patch to kdelibs 3.5.13. I rebuilt kdelibs and kdebase.

Latest results with inotify support:

1. Konqueror never updates external permission or ownership changes.

Same.

2. Konqueror updates file additions and deletions made by other users on network shares only after an unacceptably long delay.

This time I did not see any additions or deletions. The file pane remained the same. I waited a few minutes and then manually refreshed to see the change.

3. Konqueror never updates content changes to files when the file is opened through Konqueror.

Same.

4. Konqueror updates file content changes made by other users on network shares only after an unacceptably long delay.

This time I did not see any additions or deletions. The file pane remained the same. I waited a few minutes and then manually refreshed to see the change.



So let's start at the beginning.

The three URL Notifier daemons are configured to start.

Should gam_server start regardless of dnotify and inotify support?

I applied the patch provided in the mailing list. gam_server is now running when I start Trinity. I have all three URL Notifiers enabled. Things have improved. Here is a shorter list:

* Konqueror never updates external permission or ownership changes. This happens in 3.5.10 too.

* Konqueror never updates content changes to files when the file is opened through Konqueror. This happens in 3.5.10 too.

* Konqueror never updates file content changes made by other users on network shares. This happens in 3.5.10 too.

* When I perform a "touch test.txt" as another user, Konqueror reflects the new file. Likewise with rm -f test.txt. When I perform "mcedit test.txt," add some text, and save, Konqueror reflects the change as a zero byte file. This happens in 3.5.10 too.

* When I open a text file through double-clicking in konquerorsu (super user), the text editor opens with the user's profile and rights, not root's. When I instead use the "Open With..." context menu and type the full path to the text editor, then the text editor opens with root's profile. I believe this problem is related to path and environment variable problems reported elsewhere. Something is not quite right when Trinity is run in a non standard location like /opt/trinity.

I think we have resolved several issues with the gamin patch, but there remain some Konqueror file management updating issues. I think because these issues exist in 3.5.10, these bugs have existed a long time. My guess is because a significant number of people use icon view they never witness these bugs. Further troubleshooting and patching requires using list views (I use tree view all the time) to notice these problems.

A cleaned up variant of the fam/gamin patch has been committed to GIT in hash 2b03534.  The other bugs will still need to be fixed as you have noted.

I wonder if kio is actually watching for metadata updates:
http://en.wikipedia.org/wiki/Inotify

As a note to anyone who wants to look at this bug, the offending code is in tdelibs/kio/kio/kdirwatch.cpp

I'll help troubleshoot any way I can.

This is quite amazing. I applied the patch offered in an old bug report:

https://bugs.kde.org/show_bug.cgi?id=106394#c0

The patch works. :)

Regarding my previous post (Comment 16):

==================================================================
* Konqueror never updates external permission or ownership changes.

I now see file permission and ownership changes performed outside of Konqueror.

==================================================================
* Konqueror never updates content changes to files when the file is opened through Konqueror.

I now see content changes when a file is opened and edited through Konqueror.

==================================================================
* Konqueror never updates file content changes made by other users on network shares.

I now see changes performed by other users on network shares, including file size, permissions, and ownership.
==================================================================
* When I perform a "touch test.txt" as another user, Konqueror reflects the new file. Likewise with rm -f test.txt. When I perform "mcedit test.txt," add some text, and save, Konqueror reflects the change as a zero byte file.

Performing 'touch test.txt in Konsole is seen by Konqueror as is rm -f. Creating a file anew through Konsole with 'mcedit test.txt, adding some text to the empty contents, and saving, is now seen in Konqueror and reflects the correct file size.

==================================================================
All changes are immediate in Konqueror.

Much like the person who posted the patch, I won't pretend to know what this one-liner accomplishes. I am not observing any collateral effects, but I presume only long-term usage will reveal that for certain.

To Simon St James, who posted the one-liner patch --- almost 7 years ago: Thank you!

Do we want to push this patch to GIT?

Created attachment 526 [details]
Patch to fix file pane updates

There is one remaining quirk.

Konqueror does not update the file pane when select to a tmpfs directory. However, similarly, Kate does not warn about modified files when the file is from a tmpfs location.

I notice this with KDE3 as well.

I would like tp push this patch to GIT. I have been using in TDE and 3.5.10 for two months and the patch just works.

Any objections?

Hello, I'm not sure if it's related, but I too use this patch for month, and now I have another annoyance:

I'm using konqueror with "file management" profile, "split view" to see 2 directories at the same time, and "detailed view".
My source file (in left pane) is a big file (a DVD ISO image, ~4 GB).
My destination directory (in right pane) contains several files (let's say +100 files).

I copy the file to the destination directory (drag and drop from Konqueror pane 1 to pane 2). The copy takes several seconds to complete.
During that time, I can see that the destination folder is constantly refreshed, making impossible to use the right pane

(continued, sorry)
... because each refresh takes about ~1 second, it looks the directory is "blinking" during the copy: when a refresh is finished, it immediatly refreshes again, and again. It is visually unconfortable.

This should have been marked PATCHAVAIL a long time ago. :-)

The patch looks sane from here.  Go ahead and push; the refresh problem sounds like a different bug that will need to be addressed separately.

Francois, do you notice the flickering in icon view mode?

Hello, sorry for the noise, but I was wrong.
I've just tested again and my "blinking" problem occurs in Dolphin, not in Konqueror. So the patch is correct, alas there is a bug in Dolphin.

In konqueror, during the file copy, the destination folder refreshes properly only the current copied file. It is correct in any display mode (icons, detailed view, etc ...)
In Dolphin, with the same layout (2 panes: left pane: source dir, right pane: target dir), when copying a file, the right pane refreshes entirely every ~2 seconds, as if I press "Refresh" button, it is not looking good.

Yet another reason why Konqueror is better. ;-)  If you want to, go ahead and file an enhancement request on our version of Dolphin.

Darrell, go ahead and push this patch when ready, then close this report.

Thanks!

Pushed in GIT hash 1e657f6a.

This closes the bug report.