Bug 211472 - Dolphin and directory watching
Summary: Dolphin and directory watching
Status: RESOLVED FIXED
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.6
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: reproducible
: 271035 272523 273514 275849 280626 281583 291895 293313 293366 293836 294379 296005 297691 298137 302325 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-10-22 20:50 UTC by Sergey
Modified: 2014-05-02 09:58 UTC (History)
32 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.4


Attachments
Trivial and expensive workaround for Dolphin (467 bytes, patch)
2012-10-09 21:59 UTC, Hrvoje Senjan
Details
Unit test (2.62 KB, patch)
2012-11-15 07:16 UTC, Frank Reininghaus
Details
kdebug output (2.42 KB, application/octet-stream)
2013-01-20 21:55 UTC, Hrvoje Senjan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey 2009-10-22 20:50:27 UTC
Version:            (using KDE 4.3.2)
OS:                Linux
Installed from:    Debian testing/unstable Packages

Dolphin does not update the directory that is currently opened when a file is 
created/changed/copied/removed/renamed there (by non-kde appluication, e.g. from konsole, linuxdcpp, opera). Besides that, the program "fileschanged" 
does see if a file is changed (gamin is installed). So I need to press F5 while using dolphin to update the directory.

some output:
ssk@debian:~/dl$ dolphin &
[1] 5796
ssk@debian:~/dl$ kDebugStream called after destruction (from void 
KDirWatchPrivate::removeEntry(KDirWatch*, KDirWatchPrivate::Entry*, 
KDirWatchPrivate::Entry*) file ../../kio/kio/kdirwatch.cpp line 901)
Cancelled INotify (fd 12, 1) for "/home/ssk/.local/share//user-places.xbel"
^C
[1]+  Done                    dolphin
ssk@debian:~/dl$
Seems like there is some problem, but i can't find how to solve it.
Thank you.

--- System information. ---
Architecture: amd64
Kernel:       Linux 2.6.30-1-amd64
Comment 1 Dario Andres 2009-10-23 00:42:15 UTC
- 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
Comment 2 Sergey 2009-10-25 09:39:24 UTC
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.
Comment 3 Tommi Tervo 2009-10-25 10:26:01 UTC
What is your filesystem? See
https://bugs.kde.org/show_bug.cgi?id=211295
Comment 4 Sergey 2009-10-25 11:26:16 UTC
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.
Comment 5 Peter Penz 2009-12-19 19:17:04 UTC
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.
Comment 6 Sergey 2009-12-22 18:27:08 UTC
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".
Comment 7 Peter Penz 2011-04-21 15:58:26 UTC
*** Bug 271035 has been marked as a duplicate of this bug. ***
Comment 8 Peter Penz 2011-05-05 12:27:05 UTC
*** Bug 272523 has been marked as a duplicate of this bug. ***
Comment 9 Alessandro Nakamuta 2011-05-10 07:49:41 UTC
I confirm this bug on 4.6.3. The "watch" doesn't work with "non-kde" programs (GTK and Java).
Comment 10 Peter Penz 2011-05-17 23:32:33 UTC
*** Bug 273514 has been marked as a duplicate of this bug. ***
Comment 11 Parameshwara Bhat 2011-05-28 08:02:59 UTC
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
Comment 12 Parameshwara Bhat 2011-05-29 20:50:36 UTC
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.
Comment 13 Parameshwara Bhat 2011-05-29 20:52:38 UTC
why at least not give a refresh button in Dolphin?
Comment 14 Peter Penz 2011-06-17 07:05:09 UTC
*** Bug 275849 has been marked as a duplicate of this bug. ***
Comment 15 Peter Penz 2011-08-23 08:00:14 UTC
*** Bug 280626 has been marked as a duplicate of this bug. ***
Comment 16 Peter Penz 2011-09-08 07:20:56 UTC
*** Bug 281583 has been marked as a duplicate of this bug. ***
Comment 17 Peter Penz 2012-01-18 19:42:38 UTC
*** Bug 291895 has been marked as a duplicate of this bug. ***
Comment 18 Peter Penz 2012-02-04 19:15:41 UTC
*** Bug 293313 has been marked as a duplicate of this bug. ***
Comment 19 Peter Penz 2012-02-07 01:37:01 UTC
*** Bug 293366 has been marked as a duplicate of this bug. ***
Comment 20 Peter Penz 2012-02-11 13:23:00 UTC
*** Bug 293836 has been marked as a duplicate of this bug. ***
Comment 21 Peter Penz 2012-02-20 14:35:05 UTC
*** Bug 294379 has been marked as a duplicate of this bug. ***
Comment 22 Peter Penz 2012-02-20 18:05:35 UTC
*** Bug 294379 has been marked as a duplicate of this bug. ***
Comment 23 Peter Penz 2012-03-14 16:58:18 UTC
*** Bug 296005 has been marked as a duplicate of this bug. ***
Comment 24 Peter Penz 2012-04-08 08:49:25 UTC
*** Bug 297691 has been marked as a duplicate of this bug. ***
Comment 25 Peter Penz 2012-04-14 19:23:25 UTC
*** Bug 298137 has been marked as a duplicate of this bug. ***
Comment 26 2012-06-04 01:36:17 UTC
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
Comment 27 Peter Penz 2012-06-04 09:27:30 UTC
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!
Comment 28 Alexander Tkachenko 2012-06-09 09:24:04 UTC
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.
Comment 29 Ben Cooksley 2012-06-28 03:04:41 UTC
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).
Comment 30 oracle2b 2012-06-28 16:18:22 UTC
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.
Comment 31 Peter Penz 2012-07-05 16:57:14 UTC
*** Bug 302325 has been marked as a duplicate of this bug. ***
Comment 32 Johann Bergles 2012-08-05 15:45:30 UTC
still happens in Dolphin 2.1 under KDE SC 4.9
Comment 33 Hrvoje Senjan 2012-10-08 16:58:44 UTC
(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.
Comment 34 Hrvoje Senjan 2012-10-08 17:54:30 UTC
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)));
 }
Comment 35 Hrvoje Senjan 2012-10-08 18:10:30 UTC
False positive. It worked, but then stopped
Comment 36 Hrvoje Senjan 2012-10-08 18:33:08 UTC
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 :-)
Comment 37 Hrvoje Senjan 2012-10-09 21:59:57 UTC
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.
Comment 38 Frank Reininghaus 2012-11-01 14:47:05 UTC
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.
Comment 39 Frank Reininghaus 2012-11-15 07:16:03 UTC
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?
Comment 40 Philippe ROUBACH 2012-11-21 11:35:50 UTC
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
Comment 41 Emil 2012-11-28 14:50:08 UTC
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.
Comment 42 Frank Reininghaus 2012-11-29 07:14:14 UTC
(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.
Comment 43 David Faure 2012-11-29 17:11:05 UTC
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
Comment 44 Hrvoje Senjan 2012-12-01 19:04:08 UTC
I have tried to reproduce after commit, and it is indeed fixed. Thanks a lot to Frank and David! :-)
Comment 45 Johann Bergles 2012-12-12 15:41:00 UTC
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.
Comment 46 Frank Reininghaus 2012-12-12 15:46:30 UTC
(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.)
Comment 47 Tsu Jan 2013-01-19 08:10:53 UTC
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).
Comment 48 Frank Reininghaus 2013-01-19 09:53:40 UTC
(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.
Comment 49 Tsu Jan 2013-01-19 10:15:57 UTC
> 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.
Comment 50 Hrvoje Senjan 2013-01-20 21:55:36 UTC
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
Comment 51 Frank Reininghaus 2013-01-21 08:50:58 UTC
(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.
Comment 52 Tsu Jan 2013-07-12 15:07:23 UTC
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!
Comment 53 Travis Evans 2014-05-02 00:02:17 UTC
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?
Comment 54 Goran Brannstrom 2014-05-02 07:53:53 UTC
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.
Comment 55 David Faure 2014-05-02 09:58:06 UTC
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.)