KDE-Forum.org

It might depend which method is used to watch for file changes.
This can depend on the build-time configuration fo the KDE libs package and the build-teim configuration of the FAM package

Cheers,
_

Quoted

Original von anda_skoa

It might depend which method is used to watch for file changes.
This can depend on the build-time configuration fo the KDE libs package and the build-teim configuration of the FAM package

Cheers,
_

Do you have any idea if this can be solved once and for all? This seems to be a problem for a lot of people. I've seen this myself with smb shares. Even closing all konqueror instances would not help. I could only unmount them when I first killed the konqueror instance that was still in the background "in reserve mode".

Quoted

Original von frantek

there is a workaround for this problem.

when you close konqueror then atleast one process like "konquerror --silent" stays there and this is the process which blocks the resource. you can disable this background process and it's generation as you set "preloading" -> "maximum number of instances preloaded" to zero.

with this setting the blocked resource will released as soon as you close konquerror.

well - this is a workaround - NO solution.

Thanks.

Yes, I know about that workaround but it would mean losing the benefit of quicker startup of a new konqi window. And I would still have to close the konqi instance I'm working in which is already unacceptable. I'm typically working with several tabs...

Quoted

Original von frantek

and my main problem in understaning this is in the fact that i've several nearly identical setups and one releases the resource and the other don't.

with one of my setups i even have not to close konquerror. i've just to leave the CD folder and i'm able to eject the CD. this is the behaviour i would expect.

cheers
frantek

Why would any user or distro choose to configure libfam / konqueror any different than that? I assume there must be severe drawbacks, but what are they?

Quoted

Original von frantek

with a fresh debian sarge setup "famd" will be installed too.

Interesting, I think it didn't on Woody.

Can you check which packages are listed in "Reverse depends" in the output of
apt-cache showpkg fam

Quoted

afaik it is installed because gnome is the default desktop and there are some gnome apps that make use of ""famd".

On Woody gnome-commander depends on fam, but there is no such thing as a "default desktop" in Debian, so you shouldn't have it installed unless you installed some GNOME things.

Quoted

"famd" blocks also the resources. i've disabled it.

I think I remember that the problem arises from the kernel's dnofiy which keeps an open file handle for each directory it is told to monitor for changes.
FAM is very likely be compiled to use the kernel's monitoring API dnotify.

But this could also be a KDirWatcher problem, maybe it isn't telling FAM when it isn't interested in a particular directory anymore.
In this case there could be a bug report on bugs.kde.org which can be voted for.

Cheers,
_

Quoted

Original von anda_skoa

I think I remember that the problem arises from the kernel's dnofiy which keeps an open file handle for each directory it is told to monitor for changes.
FAM is very likely be compiled to use the kernel's monitoring API dnotify.

But this could also be a KDirWatcher problem, maybe it isn't telling FAM when it isn't interested in a particular directory anymore.
In this case there could be a bug report on bugs.kde.org which can be voted for.

Cheers,
_

Here's one that seems to be related:
http://bugs.kde.org/show_bug.cgi?id=37780

In fact there's a whole bunch that sound similar:
http://bugs.kde.org/simple_search.cgi?id=konqueror+unmount