Bug 211472

- When does this problem appeared ?
- Does something changes if you stop the gamin daemon ? (or play with enabling and disabling it?), and what about a restart of the whole system ?
Thanks

I tried with fam/gamin installed&running/uninstalled/installed&not running. My system uses qt 4.5.3.
I tried restarting/rebooting. But actually K3b (1.0.5, it uses qt3) can "watch" directory. And it seems like amarok (2.2) can not "watch" directory, because it needs to be restarted to find new music in the watched music folder.
May be the is a way to see more output from dolphin (how to turn the debugging output on)? Just to know if it really can use the watching function.

What is your filesystem? See
https://bugs.kde.org/show_bug.cgi?id=211295

I have ext4 and ext3 partitions. So, the results:
Dolphin (qt 4.5.3) + ext4 = watching does not work.
Dolphin (qt 4.5.3) + ext3 = watching works.
K3b (qt 3.3.8) + ext4 = watching works.
K3b (qt 3.3.8) + ext4 = watching works.

I'm not sure whether this is a KDirWatch issue or a general configuration problem, but I'm reassigning it to kdelibs/kfile as it is out of scope of Dolphin.

Some more results. I started using qbittorrent which is non-kde qt4 software.
Directory watching in the add-file dialog is working properly on ext3/ext4 partitions. So I consider it non-qt but kde-only "feature".

*** Bug 271035 has been marked as a duplicate of this bug. ***

*** Bug 272523 has been marked as a duplicate of this bug. ***

I confirm this bug on 4.6.3. The "watch" doesn't work with "non-kde" programs (GTK and Java).

*** Bug 273514 has been marked as a duplicate of this bug. ***

It is not correct to say dolphin does not update when non-kde applications make changes.Even after an Ark extraction, update does not happen.

I confirm this bug in Dolphin 1.6, kde 4.6.0, opensuse 11.4

Today I cut some files from search view in Dolphin and then pasted them to another folder in another windows of dolphin. Then I reran the search in both the windows. Both were not updated with the latest action.

Seems that this bug is a failure of dolphin to refresh it's view after a filesystem action. It fails to refresh after even it's own action.

why at least not give a refresh button in Dolphin?

*** Bug 275849 has been marked as a duplicate of this bug. ***

*** Bug 280626 has been marked as a duplicate of this bug. ***

*** Bug 281583 has been marked as a duplicate of this bug. ***

*** Bug 291895 has been marked as a duplicate of this bug. ***

*** Bug 293313 has been marked as a duplicate of this bug. ***

*** Bug 293366 has been marked as a duplicate of this bug. ***

*** Bug 293836 has been marked as a duplicate of this bug. ***

*** Bug 294379 has been marked as a duplicate of this bug. ***

*** Bug 294379 has been marked as a duplicate of this bug. ***

*** Bug 296005 has been marked as a duplicate of this bug. ***

*** Bug 297691 has been marked as a duplicate of this bug. ***

*** Bug 298137 has been marked as a duplicate of this bug. ***

I have been using git and this continues being a valid bug and it bothers quite much :(
Would it be possible to put some more focus on this problem?

TIA

Giving feedback about http://forum.kde.org/viewtopic.php?f=224&t=98940&start=15#p223685 might help to find the root-cause of this issue. Thanks!

Confirm this.
How to reproduce:
1. Open dolphin.
1. Start gimp.
2. Create some file in the directory, which is open in dolphin.
4. Watch dolphin`s window — nothing happens!
5. Press F5 and watch created file at dolphin`s window.

Thanks to the feedback on the Forum, I have been able to reduce this down to the exact use case where this occurs.

1) A folder must be viewed, then left.
2) A change to files in that folder must take place
3) The folder must be returned to

From step 3 onward, no further changes will be picked up for that folder at least. Any changes prior to that (ie. in step 2) will be picked up. 

Making changes to files in a folder while remaining in it is fine, as is leaving it, doing other things in other folders, returning to the original folder and then making changes there (ie. skipping step 2).

This is frustrating. I imagine even more so for users who don't know to manually refresh their filemanager and nor should they be required to. this only happens if the dolphin tab folder is in view .. if I i'm in another folder tab and save to a different directory and switch over to that directory it's there without any manual refresh necessary.

*** Bug 302325 has been marked as a duplicate of this bug. ***

still happens in Dolphin 2.1 under KDE SC 4.9

(In reply to comment #29)
> Thanks to the feedback on the Forum, I have been able to reduce this down to
> the exact use case where this occurs.
> 
> 1) A folder must be viewed, then left.
> 2) A change to files in that folder must take place
> 3) The folder must be returned to
> 
> From step 3 onward, no further changes will be picked up for that folder at
> least. Any changes prior to that (ie. in step 2) will be picked up. 
> 
> Making changes to files in a folder while remaining in it is fine, as is
> leaving it, doing other things in other folders, returning to the original
> folder and then making changes there (ie. skipping step 2).

This is still 100% reproducible w/ and w/o nepomuk. However, i cannot reproduce this with e.g. Krusader.

This patch is probably really sub-optimal, but at least for me, i can't reproduce the issue anymore:

--- a/dolphin/src/kitemviews/kfileitemmodelrolesupdater.cpp  2012-10-08 19:49:09.717714208 +0200
+++ b/dolphin/src/kitemviews/kfileitemmodelrolesupdater.cpp       2012-10-08 19:45:23.570541438 +0200
@@ -126,7 +126,7 @@ KFileItemModelRolesUpdater::KFileItemMod
 
     // When folders are expandable or the item-count is shown for folders, it is necessary
     // to watch the number of items of the sub-folder to be able to react on changes.
-    m_dirWatcher = new KDirWatch(this);
+    m_dirWatcher = new KDirWatch();
     connect(m_dirWatcher, SIGNAL(dirty(QString)), this, SLOT(slotDirWatchDirty(QString)));
 }

False positive. It worked, but then stopped

Frank, could you look at this when you'll have the time?
With that patch when i try to reproduce what was said in comment 29 i can't, but only the first time, after that the dir doesn't get refreshed (no new/deleted files are shown).

Also, i think it should be assigned to dolphin

@all
Sorry for the spam :-)

Created attachment 74449 [details]
Trivial and expensive workaround for Dolphin

It seems a bug is in KDirListerCache not updateing directory, so this workaround calls KDirLister::Reload on directory loading, which is exactly what happens when one refreshes view.

Thanks Hrvoje and Ben for looking into this bug and for providing detailed steps how to reproduce this! Sorry for the late reply, but I'm having trouble keeping up with review requests and bug reports for Dolphin. Not much time to debug kdelibs/KIO issues :-(

(In reply to comment #36)
> Also, i think it should be assigned to dolphin

I'm not in favor of working around this issue in Dolphin, in particular if the workaround affects performance - it looks pretty much like a bug in KDirLister/KIO (which is report is correctly assigned to), and IMHO, it must be fixed there.

@David: based on the steps that Ben provided in comment 29, do you have an idea what's going on? I don't know the KDirLister internals well, but I could try to come up with a unit test based on Ben's findings.

Created attachment 75280 [details]
Unit test

I implemented a unit test based on Ben's steps. The test fails (as expected). When changing the "if (true)" to "if (false)" and thus preventing that the directory is left and later returned to, it passes.

@David: do you have any ideas how to proceed? Or is the unit test sufficient for you to track down the bug?

Mandriva 2010.2 i586
kde 4.8.4
randomly when compressing or uncompressing the created file or folder does not appears i must refresh with "F5" key to display the new file or folder 

mageia 3 alpha 3 x86_64
kde 4.9.3
same pb

I've got the same problem but worse regarding deleting folders. The bug does always occur when deleting folders. Should I file a new bug report for this?

how to reproduce:
1) Open Dolphin and Konsole
2) create and delete a folder in Konsole in the folder Dolphin is viewing.

The folder shows up (as expected) in Dolphin but doesn't disappear until you refresh.

(In reply to comment #41)

I cannot reproduce this, and I have no idea if it's caused by the same problem or not. Filing a new bug report about a possibly related, but not reproducible issue will probably not help much. Ideally, you would wait until the present bug is fixed, try to see if your problem is fixed as well then and file a new report if that is not the case.

Git commit 75da8e8129f6bc152a781ff47fb8e741c65b584e by David Faure.
Committed on 29/11/2012 at 17:49.
Pushed by dfaure into branch 'KDE/4.9'.

Fix KDirLister forgetting to watch a directory after listing it from the cache.

Many many thanks to Frank Reininghaus for the unittest that finally made
this issue reproduceable, based on feedback from users in the bug report.

The issue: whether to watch a directory with KDirWatch is refcounted.
Each lister showing the dir counts as one, the cache itself can add one,
and does so initially. If a dir is modified while it's only in the cache,
we mark it as dirty, stop watching, and we'll simply update the directory
when showing it to the user again later. At that point we need to start
watching it again. The old code would do decr+incr, I "optimized" this in
7b9cafaaf6af (oct 2010) to fix the bug that (with an initial refcount of 1),
decr would lead to 0 temporarily.
However if the item wasn't watched anymore (initial refcount of 0), the decr
would do nothing (if (c<0) c=0), and the incr would start the watching.
With 7b9cafaaf6af this all went away (I thought decr+incr==noop), so no watching.
The proper solution is obviously incr+decr_if_not_done_before_already
(when the cache stops watching the dir because a change happened).
FIXED-IN: 4.9.4

M  +15   -7    kio/kio/kdirlister.cpp
M  +4    -0    kio/kio/kdirlister_p.h
M  +70   -2    kio/tests/kdirlistertest.cpp
M  +1    -0    kio/tests/kdirlistertest.h

http://commits.kde.org/kdelibs/75da8e8129f6bc152a781ff47fb8e741c65b584e

I have tried to reproduce after commit, and it is indeed fixed. Thanks a lot to Frank and David! :-)

The problem still happens when you download something into a folder for example with kwooty.

a while it works, then after some time it doesnt work aynmore.

Just tested today with KDE 4.9.4 Kubuntu backports Dolphin 2.1

When you longer "watch" a directory, then dolphin does "forget" watching and does not update the directory listing anymore.

(In reply to comment #45)
> The problem still happens when you download something into a folder for
> example with kwooty.
> 
> a while it works, then after some time it doesnt work aynmore.

If you can provide step-by-step instructions (preferably not involving special software), please file a new bug report about that. Thanks!

(Recycling 'FIXED' reports, even if the new problem looks very similar to the fixed one, tends to make bug reports unreadable.)

I applied Git commit 75da8e8129f6bc152a781ff47fb8e741c65b584e to kde4libs v4.8.4 (on Debian) and still see the bug, at least when creating a file with Inkscape (it isn't shown until I refresh Dolphin's view).

(In reply to comment #47)
> I applied Git commit 75da8e8129f6bc152a781ff47fb8e741c65b584e to kde4libs
> v4.8.4 (on Debian) and still see the bug, at least when creating a file with
> Inkscape (it isn't shown until I refresh Dolphin's view).

Thanks, but that information does not help us much. Lots of things have changed in kdelibs since 4.8.4, so it could be that there is some other problem hidden in the old code that is gone now. If you upgrade to KDE 4.10 soon and you still can reproduce the bug, please open a new bug report. Thanks.

> Lots of things have changed in kdelibs since 4.8.4 ...

Thank you for your reply. I came to KDE from Gnome recently and encountered this little bug. I hope it'll be fixed in 4.10.

Created attachment 76588 [details]
kdebug output

Found another way of triggering the issue (could be a different bug though, so i'm writing here if needed to report another bug report)

If one extracts archive using Ark's service menu (Extract archive here, autodetect...),  renames the extracted content (e.g. extracting soprano-2.9.0.tar.bz2 and then renames soprano-2.9.0 directory to soprano-2.9.0.bak), and then extracts the archive again, the new directory is not shown.

Further notes, works fine when extracting using tar in terminal. Also, when the renamed directory gets deleted, the new one is immediately shown (when using service menu).

Attached is the kdebug output from the moment of first extract

(In reply to comment #50)
> Found another way of triggering the issue (could be a different bug though,
> so i'm writing here if needed to report another bug report)

If the previous way to reproduce does not yield buggy behaviour for you (comment 29), it is definitely a different bug, even though the symptoms may be the same. Might be bug 311582, but the only way to be sure is to re-test when that one is fixed. If you don't want your findings to get lost in the meantime, file a new report and provide a link to bug 311582 and to the present one. Discussing similar bugs with different root causes makes bug reports very hard to read.

KDE-4.10 came to Debian at last. I just wanted to confirm that this bug is fixed in 4.10. Thank you so much!

I think I'm still seeing the bug as described in Comment 29 on KDE 4.12.4 (Arch Linux). In my case, I navigate to a particular folder, navigate away to a higher directory or via the sidebar, come back, and extract an archive using the RMB menu—the newly created file(s)/dir(s) do not appear without a manual refresh.

If I retest by restarting Dolphin and go directly to that dir and try again, it works fine. By navigating away and coming back, I reproduce it. Anyone else able to reproduce it this way?

Yes, I have almost given up on this bug ever being fixed somehow, so I do the same procedure almost by rote...

- Press F5 while in the same dir.
- Navigate to one or two levels up in the dir tree..
- Close and expand the lower branch of the directory tree.
- Press F5 like five times..

And if I'm lucky the new things will appear...  So, It is most definitely Not resolved in any way, and I would welcome any effort to fix this, and make the refresh automatic.

Travis, Goran: as written in an earlier comment:

If you can provide step-by-step instructions (preferably not involving special software), please file a new bug report about that. Thanks!

(Recycling 'FIXED' reports, even if the new problem looks very similar to the fixed one, tends to make bug reports unreadable.)