KDirLister keeps mounted devices in use

[Chris Kuhi]

On Tuesday 14 January 2003 13:33, Lubos Lunak wrote:
> On Tuesday 14 of January 2003 12:46, Chris Kuhi wrote:
> > On Tuesday 14 January 2003 11:18, Lubos Lunak wrote:
> > > On Monday 13 of January 2003 21:27, Michael Brade wrote:
> > > > Furthermore, for recognizing cdrom, floppy etc I'd need to modify
> > > > probably slow mounted to check for the "noauto" mount option, i.e. a
> > > > filesystem that is not automatically mounted with mount -a.  That
> > > > should be considered slow. Any objections to do so?
> > >
> > >  Why don't you simply implement a new function checking for manually
> > > mounted filesystems? I don't think the "noauto" option necessarily
> > > means slowness.
> >
> > I have to agree with Lubos (or is Lunak your first name?), you can't make
> > any assumptions of that sort.  As I already said above, a very good start
> > would be to implement a hook for KDE's umount command to immediately
> > release any directories it is trying to unmount and that will solve the
> > problem for most of the users who wouldn't be capable of figuring out
> > what's wrong since they'd be using the graphical interface anyway.
>
>  (Yes, it's Luboš.) I don't like this solution. I sometimes mix mouting
> using the GUI and manually where no KDE hook would help, and preloaded
> Konqy would block the unmount in such case.

I agree!  It just seems, that the solutions being discussed are all 
heuristics, and heuristics, being what they are, sometimes fail.  For those 
cases where it fails by incorrectly keeping a directory in the cache, the 
newbie user (or rather his partition ;-) ) should not be left hanging.  That 
newbie user will almost certainly be using the unmount provided by the kde 
icons, and *that* unmount should never be 'scratching its head' over 
something another part of KDE is doing.... thus the hook.  Heck, there could 
even be a command line wrapper for unmount which does that (or is that 
already possible via dcop?).  My point being, the hook should be there as a 
kind of backup.

regards,
-- 
Chris Kuhi
Email: chris at kuhi.net