KDirLister keeps mounted devices in use

[Josef Weidendorfer]

On Thursday 16 January 2003 12:16, Chris Kuhi wrote:
> On Wednesday 15 January 2003 11:20, Lubos Lunak wrote:
> >  There's no need for heuristic in the solution. Is the directory on a
> > temporarily mounted device? Yes -> don't put it in the cache. Or more
> > advanced: A directory may remain in the cache only if it's either not on
> > a temporarily mounted device or if it's on the same device as the current
> > directory.
> >
> >  The only problem  may be how to exactly know what a temporarily mounted
> > device is.
>
> Ummmm... that would be the heuristic.  Looking at the continuing discussion
> below, I'm extremely skeptical that the solution found will have a rate of
> 0% false positives, especially with the 'exotic' but ever more common
> devices such as pendrives, etc.
>
> But... I give up.  I'm not capable of contributing code to this, so I'll
> shut up except to say I predict there will be people reporting bugs on
> exactly this behaviour no matter what system you guys decide to use to
> figure out what might be unmounted until there's an explicit flag in the
> mtab which means 'might be unmounted'.
>
> regards,

Hi,

this discussion tries to find work-arounds for the symptoms of a bad design:
The problem is that DNOTIFY support in LINUX prehibits unmounting because 
there's an open file descriptor for the directory watched.

This should not be the case. In fact, there should be a "Unmounted" 
notification for watched entries. But this isn't possible with the concept 
used in DNOTIFY (open file for watched directory).
The original kernel support in IRIX for FAM was a /dev/imon device. All watch 
requests and notifications are using this device. Thus, "umount" isn't 
blocked for watched dirs.

Perhaps the best for now would be:
- use KWirWatch with STAT or FAM
- if using FAM, use STAT inside of FAM (and not DNOTIFY).
Thus, unmounting is always possible.

Put this into a FAQ as a recommandation for distributions, and redirect bug 
reports to the distributors. Perhaps, this way a kernel guy from Suse or Red 
Hat will come up with a good (correct) kernel solution.

Josef