Request for breaking hard feature freeze for an important Nepomuk service

Sebastian Trüg strueg at mandriva.com
Mon Jun 30 14:34:11 BST 2008


That is a very good point I did not even think about. In that case it would 
maybe even be better to remove the inotify support alltogether. Since this is 
not a complete solution anyway it would not do that much harm. And on the 
other side the code would become much simpler (no inotify client) and would 
not need Windows/MAC ifdefs anymore.

Cheers,
Sebastian

On Monday 30 June 2008 14:41:23 Daniel Winter wrote:
> On Monday 30 June 2008 14:25:18 Sebastian Trüg wrote:
> > But now the filewatch service uses at least KDirNotify (just learned
> > about that one) and inotify to watch for changes. This means that user
> > that only use KDE apps to handle their files will have no trouble.
> > Everyone else will also stay out of trouble unless they have more than
> > 8000 something files in their home directory (inotify's default limit) or
> > they tag files outside of the home dir.
>
> Hello Sebastian,
>
> as I am using this filewatch for some weeks now on my system (without the
> latest addition for KDirNotify)  I want to say a few things which should be
> though of.
>
> First the good: It seems to be stable (never had any crahes or memory leaks
> in it).
>
> But there are problems:
>
> When you have a lot of directorys ( believe it are directorys not files
> which get added to the inotify limit?)  it will use all inotfiy handles at
> the start of KDE. So any other request for them will fail.
>
> And that is a problem: There are other appliciations which really need
> inotify and will not even work without (for example  some svn gui clients).
>
> And there is no easy solution to disable the filewatch service (other than
> removing the .desktop file) persistent.
>
> A solution for that:  Let it check for max_user_handels on start and let it
> for example only use max 60% of them. That is a small change which will
> help to not break any other applications which rely on inotify.
>
> DanielW






More information about the kde-core-devel mailing list