Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc 3.3.3 OS: Linux According to the API documentation for KDirWatch, you can call addDir(path,watchFiles,recursive), which will watch the directory given by path and all files in that directory, emitting the created() and deleted() signals as appropriate. Unfortunately, those don't seem to work in my testing. How to reproduce: Create a test program that uses KDirWatch (I'll try to attach one later, I've been using JuK for that purpose). Setup the KDirWatch to watch a directory, taking care to set watchFiles to true when you call addDir(). Setup the signals emitted by KDirWatch to a debugging output slot in your test program. Run the test program from a Konsole. Add a file to the directory in question, and watch as no debug output is generated by your slot. Remove a file from the directory, and watch as no debug output is generated by your slot. The dirty() signal is emitted as normal, but that doesn't really help, especially for applications like JuK, which can have a list of thousands of files from different directories, that is now has to compare with the files in the directory that has changed. Expected behavior: created() or deleted() is emitted as appropriate, including the file name of the newly created file.
> According to the API documentation for KDirWatch, you can call addDir(path,watchFiles,recursive), > which will watch the directory given by path and all files in that directory, emitting the created() and deleted() signals as appropriate. * When a watched, but previously not existing directory gets created, * KDirWatch will emit the signal created(). This is quite different from what you expect - it's about waiting for a given directory (known by name in advance) to be created. > The dirty() signal is emitted as normal, but that doesn't really help, especially for applications like JuK, which can have a list of thousands of files from different directories, that is now has to compare with the files in the directory that has changed. This is what KDirLister can do for you.
On Monday 09 August 2004 09:38, David Faure wrote: > > The dirty() signal is emitted as normal, but that doesn't really help, > > especially for applications like JuK, which can have a list of thousands > > of files from different directories, that is now has to compare with the > > files in the directory that has changed. > > This is what KDirLister can do for you. Thanks, I will look into that. Perhaps the api docs for KDirWatch could have a see also entry added for KDirLister then? Regards, - Michael Pyne
According to the API you should be able to watch an already created directory with watchFiles turned on, and get created(), deleted() and dirty() signals for anyfiles in that directory - i did actully have this working in an earlier version of KDE, 3.1 posibly. However since updating to KDE-CVS, watchFiles has stopped working - the api says: if (watchFiles || recursive) { kdDebug(7001) << "addDir - recursive/watchFiles not supported in KDE 3.0" << endl; } In the addDir function. So now all you get is dirty() for the directory when a file is created within it. Where did the watchFiles/recursive support go? and will it be comming back?
On Friday 13 August 2004 15:22, theboywho@ruddyperl.com wrote: > According to the API you should be able to watch an already created directory with watchFiles turned on, and get created(), deleted() and dirty() signals for anyfiles in that directory - i did actully have this working in an earlier version of KDE, 3.1 posibly. However since updating to KDE-CVS, watchFiles has stopped working - the api says: > > if (watchFiles || recursive) { > kdDebug(7001) << "addDir - recursive/watchFiles not supported in KDE 3.0" > << endl; > } > > In the addDir function. So now all you get is dirty() for the directory when a file is created within it. Where did the watchFiles/recursive support go? and will it be comming back? It has always been this way. You can check with cvs annotate and cvs log to see that the above line has been there for long.
Will recursive or watchFiles be supported in future?
Actually, I have some very old (buggy) patches for adding support of watchFiles to KDirWatch. Give me some time, and perhaps... Regarding the "I had this working in KDE 3.1": It never worked by setting watchFiles to true. But with FAM, you *always* got created()/deleted() for files in watched dirs. But because of a bug with FAMs asynchronous nature, this "support" was removed. For KDE 4, I would like to change the API a little bit to return an opaque watch handle when adding a watch. Additionally, include user data into a watch, which simple is returned when events happen on a watch, like class UserData {}; KDirWatch::Watch* addDir(const QString& file, KDirWatch::UserData*); void created(const QString &fullpath, Watch*, UserData*);
I've been hearing a lot of news for a new mechanism intended to supersede dnotify in the Linux Kernel called inotify, by Robert Love. Perhaps KDE 4.0 would be able to support inotify, if it is available by that time? From what I've been reading it would seem to make a lot of KDirWatch's intended functionality much simpler to implement.
Josef Weidendorfer > I don't anderstand you! It was working perfectly in KDE 3.1 and KDE 3.2. Now, in KDE 3.3 it refuse to work BUT it however receive FAM signals! Very frustrating to see FAM send ALL signals and KDirWatch randomly omit a lot of them. Can you explain what are exactly those problems/bugs? Because I can't see why it doesn't work when it work! Any chance to have it working soon? Or for KDE 3.4? KDE 4.0 is so far... I need it in my program (that's even quite crutial) and can't see how to do otherwise. NB: I still have a 2.4.x Linux kernel (my modem driver is not free and willn't be ported to 2.6) and I'm stick with it. I think I'm not alone. So, please do not make a Linux 2.6.x dependant solution (even more since FAM work)!
OK. I downloaded a KDE 3.2 version of KDirWatch and imported it in my project. That's not so beautiful (that's even quite uggly) and it duplicate code but it works as before in every KDE versions: I downloaded those files (if I understand well the webcvs graphics they are those which where used in KDE 3.2.x): http://webcvs.kde.org/kdelibs/kio/kio/kdirwatch.cpp?only_with_tag=KDE_3_2_BRANCH http://webcvs.kde.org/kdelibs/kio/kio/kdirwatch.h?only_with_tag=KDE_3_2_BRANCH http://webcvs.kde.org/kdelibs/kio/kio/kdirwatch_p.h?only_with_tag=KDE_3_2_BRANCH I just added those lines at start of kdirwatch_p.h and kdirwatch.cpp (since I haven't found any kio/config.h, I assume KDirWatch will see if FAM or DNotify fail to start KDirWatch will use another method): #define HAVE_FAM 1 #define HAVE_DNOTIFY 1 And modified this line in kdirwatch.cpp: #include "global.h" // KIO::probably_slow_mounted to: #include <kio/global.h> // KIO::probably_slow_mounted To use them, we just need to replace: #include <kdirwatch.h> by: #include "kdirwatch.h" If it can be useful to other peoples, by waiting KDE 4...
> Very frustrating to see FAM send ALL signals and KDirWatch randomly omit a lot of them. Sebastien, where is the test case ? How do you observe FAM sending signals ? Maybe, does your dirwatcher only react if the last change date of a file is changed ? So, if two changes happen within 12:34:56, the last one is not recognized ?
I said FAM was sending the signals because: - I used the KDirWatch as delivred from the first KDE 3.x versions - watchFiles worked! - In the console, KDirWatch said it used FAM => Then FAM send signals when creating/modifying/deleting files in a watched directory. You're lucky my program do not need watchFiles anymore. I will re-use the class as delivered by the currently installed KDE. It will solve some compilation FAM detection (assuming FAM and DNotify exists). But he drawback is that I will do 100 KDirWatch::addFile() With addFile(), I get created() / dirty() / deleted() signals when THOSE FILES are modified. It's was I need. Only hoping that watching 1000 files doesn't hurt performances (I will program that tomorrow)...
Hi, I have fixed this bug. You can read something more here [1]. Please give me your impressions. Cheers Flavio [1] http://lists.kde.org/?l=kde-core-devel&m=118474643005104&w=2
@mpyne. I do not think you mind me closing this bug report since it seems to be too old to be applicable today. Also comment #12 stated that the issue has been fixed. Feel free to reopen if I have assumed incorrectly.