(*** This bug was imported into bugs.kde.org ***) Package: konqueror Version: KDE 2.9.1 CVS/CVSup/Snapshot Severity: normal Installed from: Compiled sources Compiler: gcc 2.96 OS: Linux OS/Compiler notes: Red Hat Linux 7.2 Standard Try mounting a device (e.g. a floppy disk) and let the konqueror instance pop up. Then change into an other directory (out of /mnt/floppy). The normal behavoir would be that you are able to unmount the disk again because you have left the directory. But unmounting the disk doesn't work because libfam still looks into /mnt/floppy and changing the directory in konqi doesn't help. You have to close konqi to be able to umount the disk. (Submitted via bugs.kde.org)
This happens on both my windows/C and on floppy Here is how to reproduce it with recent cvs: * insert a empty * open device:/ * click on the floppy - it will mount * REFRESH the opened directory - necessary (or move down in a subdir) * back out * try to unmount - will not work "Could not unmount device. The reported error was: umount: /media/floppy: unit is busy" (translated from Swedish) Since I have not seen this before I think this happens because I use "--enable-dnotify" when compiling KDELIBS (I do not use fam) My guess on what is wrong: KDE does not stop all notification watches before trying to unmount. (it should do it both when using dnotify and with fam) /RogerL
*** Bug 46472 has been marked as a duplicate of this bug. ***
*** Bug 46149 has been marked as a duplicate of this bug. ***
*** Bug 46872 has been marked as a duplicate of this bug. ***
*** Bug 41685 has been marked as a duplicate of this bug. ***
*** Bug 46897 has been marked as a duplicate of this bug. ***
KDE 3.0.4. If I mount a CD device, browse around with konqueror, then close the konqi window that I was browsing with, I can't unmount the CD. This is slightly different from what the original submitter was seeing, in that I have to close /all/ konqueror windows that were open when I mounted the CD to be able to unmount it, not just the window that I was browsing the CD with. Instances of konqueror started after the disc was mounted don't seem to cause problems. Running 'lsof /cdrom' shows a 'kdeinit: konqueror' process after I close the window showing the CD. Killing that process kills all the other open konqueror instances. This is terribly irritating, since I must interrupt my web-browsing to unmount a CD.
Hi I've tested KDE 3.1 Beta2 and the problem seems fixed, at least for me. Thanks a lot for fixing that !
I just compiled kde3.1_rc3 and noticed that if I compile kdelibs with --enable-dnotify there exists the unmounting problem. But if I compile kdelibs with --disable-dnotify unmounting works fine.
I'm using KDE3.1 from experimental deb packages [1]. For a period, I thought this problem had gone away, but perhaps I just wasn't thinking careful because it definitely still annoys me now! [1] KDE3.1 RC1 http://wh9.tu-dresden.de/kde3/karolina ./
This still exists in 3.1 RC5. I cannot umount a device before I do 'fuser -k /mnt/cdrom'. This is 100% reproducable. I amusing the Debian packages from http://hobbiton.opendoorsoftware.com/ I would really LOVE this to be fixed before the release, as this is one of the things that will annoy MANY people who use KDE (and isn't possible to figure out for novice users). Thank you!
kde-3.1_rc5 on gentoo. problem persist (I tried with some usb removable devices)
I can reproduce without dnotify enabled with latest kde cvs as of 2003-01-07
I guess this is the same problem as the one I reported with br 52152. This is one very ugly bug, it will cause may users a lot of grief using a CD-rom drive or floppy with KDE.
I couldn't get "fuser -k /mnt/cdrom" to work. What I use is umount -l /dev/cdrom umount /dev/cdrom in a script linked to a panel button.
This worked with KDE 3.1rc3 on my old system. Then I upgraded to Gentoo and installed KDE 3.1rc6. Suddenly I can't unmount my drives without closeing -all- Konqueror windows. This -must- be fixed before the release.. or people will start laughing at KDE
This bug does not appear when Compileing KDE 3.1 rc6 with "kdelibs with --disable-dnotify" on Gentoo 1.4.
Subject: kdelibs/kio/kio CVS commit by brade: Fixed #37780: stop watching a directory if it belongs to a filesystem with mount option "user" or "users". However, this still *could* fail in case of kinky systems where the sysadmin doesn't set "user" on /dev/fd0 etc. Also reduced code duplication in global.cpp by merging findPathMountPoint and probably_slow_mounted. I need someone to fix the AIX code, I have no idea how to get the mount options there, same goes for the second getmntent version (marked with a #warning). CCMAIL: 37780-done@bugs.kde.org M +49 -134 global.cpp 1.104 M +11 -3 global.h 1.56 M +5 -2 kdirlister.cpp 1.158
*PLEASE* fix this before 3.1 final.
Subject: Re: kdelibs/kio/kio On Tuesday 14 January 2003 23:23, Michael Brade wrote: > CVS commit by brade: > I need someone to fix the AIX code, I have no idea how to get the > mount options there, same goes for the second getmntent version > (marked with a #warning). > > CCMAIL: 37780-done@bugs.kde.org Is it really a "done" for the bugs system, when it doesn't even compile on more than one platform, and the author even states the above? For reference, it doesn't build on (at least) FreeBSD, and unfortunately I do not have the slightest idea about how to fix it. I will try though. A.
When it compiles on all supported platforms, and works correctly, it's "done". It's impossible to test on some platforms, because it doesn't even build!
Subject: Re: kdelibs/kio/kio On Wednesday 15 January 2003 18:16, Andy Fawcett wrote: > Is it really a "done" for the bugs system, when it doesn't even compile > on more than one platform, and the author even states the above? Yes, as the bug was for the Linux platform ;-) Also, it _should_ have compiled on _every_ platform, it's just that AIX and BSD had ismanual always set to Wrong. > For reference, it doesn't build on (at least) FreeBSD, and unfortunately Then why didn't you send the build error?! I'll commit the final fix in a few minutes which will work in any case. This will also fix *BSD systems as there are the same functions as on Linux, so I can just use getfsfile. On AIX it seems there's no routine to get the mount attribute in /etc/filesystems, also ordinary users are not allowed to mount anything. Thus I'll return false in KIO::manually_mounted in any case. Ciao,
Subject: kdelibs/kio/kio CVS commit by brade: Ok, this time for all systems and for all cases. Basically, manually mounted means it is only in mtab or it is in fstab using "noauto". I found no way to check the mount attribute in /etc/filesystems for "automatic" or "True" on AIX, also ordinary users are not allowed to mount anything; that's why on AIX KIO::manually_mounted returns always false. FreeBSD and OpenBSD should work, please test (and send me the compile errors if it doesn't!) CCMAIL: 37780-done@bugs.kde.org M +28 -11 global.cpp 1.105
This doesn't sound like a proper fix. While Konqueror is in the floppy's directory, it shouldn't be possible to unmount it. When Konqueror exists that directory, FAM should stop watching it. The fact that it doesn't stop watching it - is the actual bug. Konqueror should use FAM in any case, but we should take care so that FAM would stop watching the directory when we leave it (including closing Konqueror's window).
"While Konqueror is in the floppy's directory, it shouldn't be possible to unmount it.". In my (wierd) ideal world: CDs & Floppys can be unmounted and ejected at any point in time. If a user has a Konqueror window in a directory that's unmounted, the Konqueror window should just update and show now files.. (mounted devices are only lucked when they are read from/written to). That's just my idea of ideal behavour, and is not really important (I'm just this dude, you know, all I ever done for KDE is translate stuff, yet KDE has given me a great desktop environment and tons of great programs)
I can still reproduce the problem on kde-3.1.1 on debian/unstable. mount /dev/scd0 on /cdwriter type iso9660 (ro,noexec,nosuid,nodev,user=micha) lsof /cdwriter kdeinit 3545 micha 18r REG 11,0 712100162 57582 /cdwriter/<some file> ps 3545 PID TTY STAT TIME COMMAND 3545 ? S 0:08 kdeinit: konqueror -mimetype text/html http://dot.kde.org and eject fails therefore. No famd running here.
System : Debian unstable KDE version: 3.1.1 I can confirm this bug as well. The funny thing is, that I have a dvd-rom and a dvd-burner on my stystem. With the dvd-burner I can both mount, umount and eject dvds, however, with the dvd-rom I can mount and umount dvd, but not eject them. When attempting to eject the cdrom via the context menu provided by the dvd-rom icon on the desktop, I get a popup saying "Eject /dev/cdrom failed!" I have to log out of KDE and log in again and then it is possible to eject the dvd-rom. Beat
With regard to my previous post: it seems, that my problem with the dvd-rom not being able to eject dvds is a bit different from the original bug report, which stated the unability to umount a cdrom. Well, in my case it is the inability to _eject_ a cdrom with the dvd-rom device via the dvd desktop icon. It is most probabily still a KDE related bug, as I am able to flawlessly mount / umount / eject a dvd on a Linux console. This is also true within the KDE environment in case the dvd-rom is mounted/umounted/ejected in the Konsole. It is even possible to eject the cdrom with via the desktop icon, if the dvd-rom was mounted via the Konsole. However, it is not possible to eject the cdrom, if it was mounted via the desktop icon (this produces the error "Eject /dev/cdrom failed!" in a popup window and following error if one attempts to do the same via the Konsole: wind:beat> eject /mnt/cdrom eject: unable to eject, last error: Invalid argument One more strange thing I found out: If one mounts a cdrom via the desktop icon and waits a certain time (a few minutes) it is possible to eject it also via the context menu of the desktop icon or via the Konsole (without errors this time). That's strange. This problem is probably not be related to the hardware I'm using, as this computer is a few years old and it has alwyas worked so far... Beat
One more thing, I found out that root can eject a cdrom mounted via the dvd-rom desktop icon, while a normal user cannot do this immediately. Follwing error does occur with root ejecting a cdrom immediatly after being mounted by the user via the desktop icon: wind:/home/beat# eject /mnt/cdrom eject: unable to eject, last error: Invalid argument wind:/home/beat# However, the cdrom is ejected. Sorry for all the mails I created and reporting the error probably in the wrong bug category! Beat
I'm guessing this should either be relogged, if it's reproducibly not working, or reopened.
I was able to resolve the CD-Rom eject problem by removing .kde, .kderc, .mcop, .mcoprc, and .qt in my home directory and relogging into my KDE account. Therefore no need to relog or reopen this bug! Thanks! Beat
Guys PLEASE fix it.... I have a bit tired of this bug for last 10 months. I have 3.1.1 and it's still there!
there are still some cases hiding it seems
Jens, can you tell me what package I need to upgrade from CVS to fix the problem? A note reagrding the bug. If I open multiple Konqueror windows, I have to close only the windows which was "visiting" CD-ROM to umount it. If I use tabbed mode, I have to close entire window with all tabs (closing just the tab used to view CD doesn't help). (See how it's frustrating if I have 8 tabs opened with various local and remote addresses and I need to eject my CD!)
Subject: Re: Unable to unmount device, because of Konqi & libfam On Tue, May 27, 2003 at 08:16:19PM -0000, Sergey A. Galin wrote: > Jens, can you tell me what package I need to upgrade from CVS to fix > the problem? Sorry, no. :) I only do full upgrades (because I use the debian binaries provided at hobbiton.opendoorsoftware.com). > A note reagrding the bug. If I open multiple Konqueror windows, I have > to close only the windows which was "visiting" CD-ROM to umount it. If > I use tabbed mode, I have to close entire window with all tabs Here, Konqueror realizes that the CDROM is supposed to be umounted and removes all locks. So I can do RMB->"eject" while Konqueror is still on the drive, the konq window will update to "nothing" (ie empty directory) and the CD will be ejected. Unfortunately, in the CVS I have (about 2 weeks old) Konqueror crashes after about every second successful (!) mount of a removable media. =;)
I am running KDE 3.1.1 and have several samba shares mounted. Sometimes the network gets really slow (we have an old COAX network with really bad cables) and the konq window that was listing the network files gets slow as well. (Of course I should blame my hardware first, but this setup is perfect for showing konq's worst behaviour) The annoying thing is that *ALL* of konqueror gets very slow after I have accessed a network share that has become unreachable. Even a 'save as' dialog in KWord gets slow, even though this dialog did not access the samba mounts. As soon as the user has closed all views listing a particular directory, konqueror should forget all about it immediately.
Well, i'm running KDE CVS HEAD (fairly recent) and if i go to devices:/ and mount a cdrom and then close the konq window and try to unmount it, it says its busy. A call to lsof says konq is still holding files in /mnt/cdrom. I have to kill it to be able to unmount it. This is a VERY annoying bug. The sad thing is i remeber a time long ago where i could unmount it with the konq window open in /mnt/cdrom and konq would just update and show nothing. That is how it should work. I'm using the live cvs kde ebuilds by Dan Armak for Gentoo 1.4.
Subject: Re: Unable to unmount device, because of Konqi & libfam I had a new experience this weekend. I'm also running CVS HEAD (from about a week ago) and would propose the following: Kill all kio_thumbnail tasks working in a directory that is about to be umunted.
Gave this bug a new try using kde-3.1.2: I keep on window open with file:/cdrom and then mount/umount various CDs. Some work find, that is clears the window as things are unmounted. But opening a cd with a .avi + hovering over it to get the sound previewed results in the CD being unmountable - not with a device busy but with a eject failed message dialog. Closing all konqueror windows lets me unmount the cd again... Hm.
Sorry for the long text. But this is the single most annoying bug i'd like fixed before 3.2 :) That and the fact i cant define distribution lists in kaddressbook... Hmm, killing kio_thumbnail does nothing in my case as it is konqueror itself holding the dir open (or fam if i have it running) . I actually have to kill konqueror/fam. The following case is with fam running: Go into devices:/ and mount a cdrom with slackware 8.1. Do "lsof |grep cdrom" this is the result: fam 978 storm 16r DIR 11,1 4096 61036 /mnt/cdrom/kernels fam 978 storm 17r DIR 11,1 4096 61440 /mnt/cdrom/slackware fam 978 storm 18r DIR 11,1 2048 65868 /mnt/cdrom/kernels/adaptec.s fam 978 storm 19r DIR 11,1 2048 65992 /mnt/cdrom/kernels/bare.i fam 978 storm 20r DIR 11,1 2048 66242 /mnt/cdrom/kernels/ibmmca.s fam 978 storm 21r DIR 11,1 2048 66364 /mnt/cdrom/kernels/jfs.i fam 978 storm 22r DIR 11,1 2048 66744 /mnt/cdrom/kernels/lowmem.i fam 978 storm 23r DIR 11,1 2048 67120 /mnt/cdrom/kernels/old_cd.i fam 978 storm 24r DIR 11,1 2048 67242 /mnt/cdrom/kernels/pportide.i fam 978 storm 25r DIR 11,1 2048 67368 /mnt/cdrom/kernels/raid.s fam 978 storm 26r DIR 11,1 2048 67710 /mnt/cdrom/kernels/scsi.s fam 978 storm 27r DIR 11,1 2048 67828 /mnt/cdrom/kernels/scsi2.s fam 978 storm 28r DIR 11,1 2048 67948 /mnt/cdrom/kernels/speakaha.s fam 978 storm 29r DIR 11,1 2048 68074 /mnt/cdrom/kernels/speakup.i fam 978 storm 30r DIR 11,1 2048 68198 /mnt/cdrom/kernels/speakup.s fam 978 storm 31r DIR 11,1 2048 68322 /mnt/cdrom/kernels/speakup2.s fam 978 storm 32r DIR 11,1 2048 68448 /mnt/cdrom/kernels/usb.i fam 978 storm 33r DIR 11,1 2048 68564 /mnt/cdrom/kernels/usb.s fam 978 storm 34r DIR 11,1 2048 68680 /mnt/cdrom/kernels/usb2.s fam 978 storm 35r DIR 11,1 2048 68798 /mnt/cdrom/kernels/usbaha.s fam 978 storm 36r DIR 11,1 2048 69050 /mnt/cdrom/kernels/xfs.i fam 978 storm 37r DIR 11,1 2048 69166 /mnt/cdrom/kernels/xt.i fam 978 storm 38r DIR 11,1 2048 69280 /mnt/cdrom/kernels/zipslack.s fam 978 storm 40r DIR 11,1 18432 112844 /mnt/cdrom/slackware/a fam 978 storm 41r DIR 11,1 14336 112952 /mnt/cdrom/slackware/ap fam 978 storm 42r DIR 11,1 10240 113318 /mnt/cdrom/slackware/d fam 978 storm 43r DIR 11,1 4096 113426 /mnt/cdrom/slackware/e fam 978 storm 44r DIR 11,1 2048 113534 /mnt/cdrom/slackware/f fam 978 storm 45r DIR 11,1 24576 113766 /mnt/cdrom/slackware/gnome fam 978 storm 46r DIR 11,1 2048 113882 /mnt/cdrom/slackware/k fam 978 storm 47r DIR 11,1 8192 113990 /mnt/cdrom/slackware/kde fam 978 storm 48r DIR 11,1 10240 114102 /mnt/cdrom/slackware/l fam 978 storm 49r DIR 11,1 18432 114338 /mnt/cdrom/slackware/n fam 978 storm 50r DIR 11,1 4096 114572 /mnt/cdrom/slackware/t fam 978 storm 51r DIR 11,1 4096 114688 /mnt/cdrom/slackware/tcl fam 978 storm 52r DIR 11,1 6144 114800 /mnt/cdrom/slackware/x fam 978 storm 53r DIR 11,1 10240 114908 /mnt/cdrom/slackware/xap fam 978 storm 54r DIR 11,1 2048 115020 /mnt/cdrom/slackware/y ... Get out of /mnt/cdrom back to devices:/ and try to unmount. Busy. Close the window. Busy. Do "lsof|grep cdrom", exactly same result as before. Kill fam. Now "lsof|grep cdrom" output is just: kdeinit 985 storm 128r DIR 11,1 4096 61036 /mnt/cdrom/kernels kdeinit 985 storm 129r DIR 11,1 4096 61440 /mnt/cdrom/slackware ... which is: 985 ? S 0:03 kdeinit: konqueror -mimetype inode/directory devices:/ .. although i already closed that window. Kill that process and it unmounts.
Wow this bug has really made a blatant reentry into my fresh kde 3.1.2 setup! This problem really dissonates with the further excellent quality of KDE. I compiled kde with -disable-dnotify (it was fixed by that previousy!?!?) libfam is enabled though. When I turn off fam (when the problem occurs) , I can suddenly umount my CDrom drive, but life is no fun without fam and dnotify...
i think i duplicate this bug in bug number 58504 . so i gone on here from now
*** Bug 58504 has been marked as a duplicate of this bug. ***
Retested - my earlier procedure to force this does not work anymore. But another one does: (try a lsof /media/floppy after each step) * insert a floppy * open device:/ * click on the floppy - it will mount * REFRESH the opened directory - necessary (or move down in a subdir) * move out, select devices:/ from history (back out will not trigger the bug, if back is used the usage will dissappear) (Preloading makes it possible to even close konqueror at this point) * try to unmount - will not work BTW - a "lsof mountpoint | head" list in the error message would be useful... Even if this specific bug is fixed - sometimes you forget a shell e.t.c. If it would be integrated with ksysguard it would be even better!
ok by now it's seems that kdeinit still lockup i.e after looking in text file from cd it's still lockup on it so the it's look like it's still used. here is lsof output: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME kdeinit 17094 maor 134r DIR 11,1 2048 60486 /mnt/cdrom2/compat20
Fresh (compiled yesterday) in kde CVS: Problem persistent as ever, especially where "preloading" of konqueror is enabled (by default?) and you can't close all konqueror windows :( :( I would be satisfied when the rightclick menu would use "umount -l" on both unmount and eject. It will then unmount , whatever I am doing. I fear that eject can't be configured to use different umount commands however. Maybe there is a way to configure the the exact umount command for kde?
I use this evil thing: #!/bin/sh UNUSE_DEV=/mnt/cdrom /bin/kill `/usr/sbin/lsof -t $UNUSE_DEV` eject $UNUSE_DEV These suckers who keep the thing locked deserve it! 8-D Can anyone tell if it locks CD on system with supermount?
*** Bug 54486 has been marked as a duplicate of this bug. ***
*** Bug 52237 has been marked as a duplicate of this bug. ***
*** Bug 53087 has been marked as a duplicate of this bug. ***
*** Bug 61299 has been marked as a duplicate of this bug. ***
Yes, Sergey, in fact supermount does not release the cd-rom until all open konqueror-windows are closed. This _is_ annoying. :-(
Those of you who have not voted for this bug please do so. That way it gets high in the list of most hated bugs and has a higher chance of being fixed.
Hi voters, I am trying to check if there could be a economic possibility in bug fixing for KDE. Right now there are fourty voters for this bug - how much would PAY to get this bug fixed before KDE 3.2 is released? Please respond to me directly, even if the answer is nothing. (Please use Euro or US Dollars from your [companie] perspective, even if all money would en up in some banks wallet).
Subject: Re: Unable to unmount device, because of Konqi & libfam On Saturday 16 August 2003 10:33 pm, you wrote: > ------- Additional Comments From roger.larsson@norran.net 2003-08-17 00:32 > ------- Hi voters, > > I am trying to check if there could be a economic possibility in bug fixing > for KDE. Right now there are fourty voters for this bug - how much would > PAY to get this bug fixed before KDE 3.2 is released? > > Please respond to me directly, even if the answer is nothing. > (Please use Euro or US Dollars from your [companie] perspective, even if > all money would en up in some banks wallet). I did not vote for this bug on behalf of my company; they currently do not use Linux on the Desktop. This is an irritation that struck a cord as a home user and, as such, I have no money to spare for such an endeavour. I can see that ths might be a mechanism that could be used to accelerate development of fixes that affect enterprise deployments, but I think that it might prove controversial because other users, who may also be developers who are contributing their time for free, might feel that their pet fixes are being unfairly delayed.
"I am trying to check if there could be a economic possibility in bug fixing for KDE. Right now there are fourty voters for this bug - how much would PAY to get this bug fixed before KDE 3.2 is released?" Yes, it is VERY annoying that this bug does not seem to get much priority. But: Money is NOT the force that drives the KDE project, and hopefully it never will. The KDE community is a democracy, every participant has equal voice. It would be *very* bad for KDE if the voices of people who have lots of money will sound louder than the voice of others. The strength of KDE is that it evolves naturally, without any single individual telling everyone else what should be done and what not. It is great if people have the opportunity to sponsor KDE developers, but please, NEVER influence their work by offering money to get something done. Do like me, Vote and Beg: PLEASE fix this bug! :-)
Ok, i add my voice to the previous commenter. Will somebody please fix this bug. It renders the device support in KDE totally useless! Maybe if someone changed the severity to critical someone would notice, as this renders a part of KDE useless. I can even test the fixes. I'm running HEAD and dont mind recompiling kdelibs/ kdebase just to test stuff.
I join the others to say that this bug has been trying users for a long time now... I noticed that it was worse than ever if thumbnails are activated in Konqy. In the past, killing the kio_thumbnail process was enough to unlock the device, but now I must kill konqueror itself. Thanks for your attention!
I have experienced the problem that I cannot eject a CD containing AVI files after accessing it with Konqueror (3.1.1 from SuSE Linux 8.2). Could this be related to the feature that displays meta-info about codecs, length, resolution, etc. as tooltip?
Found it. kio_thumbnail seems to be innocent (at least for me, klauncher kills it after 30 seconds of inactivity). However the KDirLister fix only works with the mountpoint itself, not for its subdirs. KIO::manually_mounted /mnt/cdrom/foo : false Not good. Will fix.
new hobby "killing summaries"? ;)
Summary back.
Subject: kdelibs/kio/kio CVS commit by faure: 4 bugfixes, among which a very important one for the most hated bug (#37780) * Fixed manually_mounted, a previous call to a get_mount_info method could cache info about the device but _without_ the ismanual information, so we need to retrieve this information in this case (this made the KDirLister fix for 37780 sometimes not work). * Don't hardcode /etc/fstab * Remove very strange destructor call in Solaris code, useless and could crash? * Fixed obvious copy-n-paste error when storing info in cachedDevice This doesn't completely fix 37780 though, we still have kioslaves laying around for a long time (e.g. kio_audiocd or kio_thumbnail), looks like a klauncher bug. CCMAIL: 37780@bugs.kde.org M +15 -5 global.cpp 1.120 --- kdelibs/kio/kio/global.cpp #1.119:1.120 @@ -1275,4 +1275,12 @@ extern "C" void endvfsent( ); #endif +#ifndef FSTAB +# ifdef _PATH_FSTAB +# define FSTAB _PATH_FSTAB +# else +# define FSTAB "/etc/fstab" +# endif +#endif + // There are (at least) four kind of APIs: // setmntent + getmntent + struct mntent (linux...) @@ -1366,5 +1374,4 @@ QString KIO::findDeviceMountPoint( const } fclose( mnttab ); - devname.~QCString(); #else @@ -1612,8 +1619,11 @@ static QString get_mount_info(const QStr if (cachedDevice && (stat_buf.st_dev == cachedDevice->device)) { + bool interestedInIsManual = ismanual != Wrong; isautofs = cachedDevice->isautofs; isslow = cachedDevice->isslow; ismanual = cachedDevice->ismanual; fstype = cachedDevice->fstype; + // Don't use the cache if it doesn't have the information we're looking for + if ( !interestedInIsManual || ismanual != Unseen ) return cachedDevice->mountPoint; } @@ -1788,7 +1798,7 @@ static QString get_mount_info(const QStr STRUCT_SETMNTENT fstab; - // TODO: #define FSTAB (FSTAB_FILE?), important for Solaris - if ((fstab = SETMNTENT("/etc/fstab", "r")) == 0) + if ((fstab = SETMNTENT(FSTAB, "r")) == 0) { continue; + } bool found = false; @@ -1829,5 +1839,5 @@ static QString get_mount_info(const QStr cachedDevice->isautofs = isautofs; cachedDevice->isslow = isslow; - cachedDevice->ismanual = isslow; + cachedDevice->ismanual = ismanual; cachedDevice->fstype = fstype; }
Sorry for the summary killing, it was a KHTML/Qt bug - should work this time. After more testing, I can't actually find a case that still doesn't work. I was wrong about kio_audiocd: although it keeps running, it only cares about the device, not about the mountpoint, so it doesn't prevent unmounting. kio_thumbnail doesn't seem to do so either (I can unmount although it's running). It's really fam that kept the file descriptors opened - BTW the best way to see that is ls -l /proc/`pidof fam`/ld | grep cdrom The previous commit fixes that, so AFAICS this bug is fixed. If anyone is running CVS HEAD, please update, and check if you still have problems. If so, please give instructions on how to reproduce the problem.
I'll test it as soon as peer stops resetting my connection to cvs.kde.org :)
Seems OK, now I can even view a file on the device and unmount :-) I opened a picture file in gimp and a html file in konqueror... It should be /fd and not /ld in the ls command, like this: ls -l /proc/*/fd/ | grep cdrom
Yep, its working now. But i still need to close the konqueror window to unmount. I seem to remember a version of KDE where i could unmount with konq open and konq would just show no files. This would be optimal. Is this the intended behaviour or a remaining bug ?
Yes, there was a KDE version where I could unmount the cdrom device anytime, anywhere, and I think this should be the default behaviour. If I remember correctly, this version is 3.1rc5. In 3.1rc6, this bug appears. This is the more annoying bug in KDE by now in my opinion.
ok now it's seems work ok when i leave the cd directory i can umount device with no problem till now no problem finally looks like a sulotion to a very annoying bug. thx a lot.
Hmmm, spoke too soon. Sometimes even if i close the konq window, some processes are still around trying to generate thumbnails supposedly. Kill them and it unmounts.
How long this list is ... But the Bug still exists in Konqueror 3.1.3
Subject: Re: Unable to unmount device, because of Konqi & libfam > How long this list is ... But the Bug still exists in Konqueror 3.1.3 And your point is? It's fixed in CVS, we can't change the past though.
Really fixed? I hear that it's fixed weekly for last few months.
Subject: Re: Unable to unmount device, because of Konqi & libfam > Really fixed? I hear that it's fixed weekly for last few months. Well there was more than one bug affecting this. Michael Brade fixed it, but the code he used (to determine mount points) had a bug, so it was still broken in some cases. That's what I fixed. Now it works fine for me. What can I say? If anyone finds a case where it doesn't work, WITH THE CURRENT CVS VERSION, then please say so. Otherwise, yes, this is assumed to be fixed.
Its still not totally fixed. You can't unmount/eject the medium with the konq window opened & in the mount dir. You could do that in the past before this bug appeared. But, yes, you can now unmount if you close the window.
Additionally, i just tested it again just to be sure, and just going out of the mount dir doesnt do it. You have to close the window.
*** Bug 64950 has been marked as a duplicate of this bug. ***
*** Bug 64996 has been marked as a duplicate of this bug. ***
This bug appears 100% fixed for me, as of 2003-10-20's CVS. I'm able to unmount at any time. If I still have a Konqueror window open with the contents of the mounted media, the window is emptied and the media unmounted. Thank you!
$ ldd `which konqueror` | grep -i fam libfam.so.0 => /usr/lib/libfam.so.0 (0x411fc000) $
No, it is not completely fixed. I cant unmount without closing the konqueror window.
*** Bug 67195 has been marked as a duplicate of this bug. ***
*** Bug 67256 has been marked as a duplicate of this bug. ***
Not to me -- i am using CVS build for SuSE from adrian, (13 nov 2003) and still -- konq. blocks media after exit, not letting to unmount it. i always have to find the instance, blocing it (using lsof command) and kill it manually looks like it is because of preloading. it also blocks such things as submount or supermount and stuff.
Here, this bug isn't yet resolved, because of Konqueror's preloading. I cannot umount the cdrom device currently. fuser -k doesn't help, fuser -v /cdrom doesn't show anything but "kernel mount", and Konqi doesn't umount the device. I suggest we either kill the preloaded konqueror processes if they don't belong to active windows, OR make them chpwd $HOME or / on umount. (if that's possible). Here we are: get1418:~# lsof|grep cdrom kdeinit 4215 benecke 15r REG 3,64 39990 65866 /cdrom/acrobat/INSTALL kdeinit 4215 benecke 16r REG 3,64 2873856 66244 /cdrom/acrobat/READ.TAR kdeinit 4215 benecke 17r REG 3,64 22054 66366 /cdrom/acrobat/ReadMe get1418:~# ps ax|grep 4215 4215 ? S 0:04 kdeinit: konqueror --preload
Subject: Re: Unable to unmount device, because of Konqi & libfam > get1418:~# lsof|grep cdrom > kdeinit 4215 benecke 15r REG 3,64 39990 65866 /cdrom/acrobat/INSTALL > kdeinit 4215 benecke 16r REG 3,64 2873856 66244 /cdrom/acrobat/READ.TAR > kdeinit 4215 benecke 17r REG 3,64 22054 66366 /cdrom/acrobat/ReadMe This is more than the current-working-directory of konqueror though, that's 3 files on which it keeps a hold independently, isn't it? Did you use an embedded text viewer to view INSTALL and ReadMe? If not, I wonder what it could be. The thumbnail preview (but not the ioslave here)? The tooltip preview? The folder-reflect-contents feature? Does deactivating all those features help? I don't doubt that going to $HOME in konq helps - but that's probably because it terminates all those features at the same time. We need to find which feature creates the problem...
Subject: Re: Unable to unmount device, because of Konqi & libfam On Mon, Nov 24, 2003 at 09:04:20AM -0000, David Faure wrote: > > get1418:~# lsof|grep cdrom > > kdeinit 4215 benecke 15r REG 3,64 39990 65866 /cdrom/acrobat/INSTALL > > kdeinit 4215 benecke 16r REG 3,64 2873856 66244 /cdrom/acrobat/READ.TAR > > kdeinit 4215 benecke 17r REG 3,64 22054 66366 /cdrom/acrobat/ReadMe > This is more than the current-working-directory of konqueror though, > that's 3 files on which it keeps a hold independently, isn't it? Yes. There was no konq window open at the time. It was a background process. > Did you use an embedded text viewer to view INSTALL and ReadMe? Yes. > If not, I wonder what it could be. The thumbnail preview (but not the > ioslave here)? There was nothing to generate a preview for (and IMHO the preview creates a process called kio_thumbnails, right?) > The tooltip preview? The folder-reflect-contents feature? Does > deactivating all those features help? I'll try next time I notice this. > I don't doubt that going to $HOME in konq helps - but that's probably > because it terminates all those features at the same time. We need to > find which feature creates the problem... I'd guess the problem is that the preloaded Konq doesn't close all its files even if the active window is being closed.
This bug is still present in 3.1.4. Using the kpanel quick browser to explore a mounted cdrom makes it impossible to umount it and killing the panel isn't really an option. This is the fstab entry related to my cdrom. /dev/scsi/host0/bus0/target0/lun1/cd /mnt/cdrom iso9660 user,noauto,ro 0 0 I'm running kde 3.1.4 on top of gentoo 1.4. Thanks for the attention!
Hello! The bug is still present in SuSE 9.0 kde 3.1.4 with SuSE's official upgrade. If i insert a CD with an .avi file in the root dir, i cannot umount it because there is a background Konq. process similar to this: kdeinit: konqueror -inode/directory /dev/cdrom . I don't remeber correctly what is the running process. With another type of data CD umounting works perfect. Bye
This appears to be fixed in 3.1.94. -- JRT
Still not completely fixed. Yes, i can unmount if i close the or back out of the mount point, but i still cant simply umount with a konq window opened in the mountpoint. This was possible in previous kde versions (not sure what version exactly). That is the intuitive behaviour (if there is such a thing).
Perhaps this should be reopened, since there seems to be some dispute as to whether the problem is fixed? It seems odd to show so much activity on a 'Resolved' bug.
The problem wich i reported with .avi files in CD root directory can be fixed: Konqueror -> Preferences -> Konqueror preferences -> Performance (the last in the list) -> Maximum number of instances kept preloaded -- should be set to 0!
With Fedora core 1 and kde 3.2 beta2 binary for fedora installed. As a non-root user, insert fedora cd1 in driver(cancel the root login), use konqueror go to the cd directory(/mnt/cdrom) then the Fedora directory, cannot umount cdrom(use menu System - Disk Management) even after closing konqueror. have to exit kde and come back to umount. No problem with fedora cd2 or cd3 though. but the following processes take years to stop(or never) after closing konqueror, with or without umount problem. 11868 ? S 0:00 kdeinit: kio_file file /tmp/ksocket-jinp/klauncherfUKtBb.slave-socket /tmp/ksocket-jinp/konquerorSpBAqa.s 11869 ? S 0:00 kdeinit: kio_file file /tmp/ksocket-jinp/klauncherfUKtBb.slave-socket /tmp/ksocket-jinp/konquerorScilAa.s 11870 ? S 0:00 kdeinit: kio_file file /tmp/ksocket-jinp/klauncherfUKtBb.slave-socket /tmp/ksocket-jinp/konquerorrRUukb.s 11871 ? S 0:00 kdeinit: kio_file file /tmp/ksocket-jinp/klauncherfUKtBb.slave-socket /tmp/ksocket-jinp/konquerortLeFpc.s 11872 ? S 0:00 kdeinit: kio_file file /tmp/ksocket-jinp/klauncherfUKtBb.slave-socket /tmp/ksocket-jinp/konquerornEPUaa.s
Re: bug#37780c94 the FC1 problems being reported here most likely have very little to do with this bug, as I'm fairly certain that the FedoraCore packages are/were built *without* libfam support. Re: bug#37780c89, this has been worked on (and apparently fixed) only for the KDE_32 branch.
Browsing using Services sidebar (in this case Devices) can cause trouble... I used it to mount my windows partion (clicking the +). Then I moved down the structure, still using the sidebar. Right window is not moved. Then I close the tree with '-' for the toplevel (disk). Right click on disk, select unmount "umount: /windows/C: device is busy Please check that the disk is entered correctly." # lsof /windows/C COMMAND PID ... NAME kdeinit 2070 ... /windows/C/1_Pict kdeinit 2070 ... /windows/C/1_Pict/2003 kio_devic 13945 ... /windows/C/1_Pict kio_devic 13945 ... /windows/C/1_Pict/2003 After a refresh the kios were gone. # kill 2070 This kills the konqueror I used to brows into the directory. Enough for me to reopen the bug - can you reproduce? one is enough...
Re: Comment #91 Although this may have worked differently in previous versions, the behavior described is correct. If you are actually using the mounted device then it IS busy. That is, if you have any directory which shows files on the mounted device open in a KFM window then you are using the mounted device and it is correctly reported as busy. So, it gets closed again. -- JRT -- JRT
Subject: Re: Unable to unmount device, because of Konqi & libfam On Friday 30 January 2004 23:02, James Richard Tyrer wrote: > If you are actually using the mounted device then it IS busy. That is, if you have any directory which shows files on the mounted device open in a KFM window then you are using the mounted device and it is correctly reported as busy. Yes. If anyone thinks the unmount operation should automatically close that window, this requires special support in KDE (using DCOP communication) - which would be a different wishlist item.
I don't think it should close the window, i think it should unmount and then show no files in the window. That was the behaviour in KDE in 2.x versions. And that behaviour was very convenient.
Created attachment 4446 [details] Series of snapshot on how to reproduce the problem Mount floppy, browse into subdirectory with sidebar.
Created attachment 4447 [details] #2: Change view
Created attachment 4448 [details] #3: close '-' the floppy directory structure too
Created attachment 4449 [details] #4: Trying to unmount the floppy - device is busy
I am not using the mounted device. I do not have ANY directory which shows files on the mounted device open in a KFM window so I am not using the mounted device and it is incorrectly reported as busy. Reopening :-)
Subject: Re: Unable to unmount device, because of Konqi & libfam On Saturday 31 January 2004 00:19, Roger Larsson wrote: > I do not have ANY directory which shows files on the mounted device open in a KFM window so I am not using the mounted device and it is incorrectly > reported as busy. It would help if you followed the instructions in some comments of this (now very long) BR, to find out which process is keeping a hold on the floppy directory. Does it help if you close the sidebar? (press F9). I suspect the tree might keep watching the dir...
Yes, it is the sidebar! Sequence is like follows, in sidebar do: Click '+' in front of Floppy click '+' in front of New folder [important] click 'Devices' click '-' in front of Floppy (closing the hierarchy) right click on floppy, select unmount - fails press "F9" to close sidebar press "F9" again to reopen right click on floppy, select unmount - success Interesting observation: Click '+' in front of Floppy, right click on floppy, select unmount - success, but the subdirectory "New folder" was and remains visible in sidebar!!! Interesting observations:
Test case for sidebar: Open Konqueror Open SideBar Click '+' in front of Floppy Click Floppy in SideBar Do something in KFM window Click '-' in front of Floppy in SideBar Click on Devices RMB Floppy in the KFM window and choose: "Unmount" IWFM In any case, this would be a bug ONLY with the KIO-Slave for Devices. The secondary bug remains. The Floppy device's tree remains open after it is unmounted. -- JRT
I had the same problem with my usb memory stick too (/dev/sda1). It always tells me that the device is used ... and so i couldn't unmount it. Wouldn't it be nice if kde could tell me which part is using the device ?? Using KDE 3.2RC1 ...
Subject: Re: Unable to unmount device, because of Konqi & libfam > ------- Additional Comments From scherfa@web.de 2004-01-31 12:29 ------- > I had the same problem with my usb memory stick too (/dev/sda1). It always > tells me that the device is used ... and so i couldn't unmount it. Wouldn't > it be nice if kde could tell me which part is using the device ?? Using KDE > 3.2RC1 ... Hello, I have a whishlist report for that. Actually it is a Kdf whish but I guess it could be made more general. http://bugs.kde.org/show_bug.cgi?id=62079 J.A.
I believe that you can now unmount devices, but that there are still some minor issues which will probably not get fixed till 3.2.1. If anyone is using a 3.2 release candidate or are using 3.1.4 or 3.1.5 and are still having problems with not being able to unmount a floppy or CD, please advise me by private mail: James Richard Tyrer <tyrerj@acm.org>. If you are having problems with devices other than disks, please open a new bug report with a specific case. I will open a new one for the SideBar issue since I can reproduce that on my system. Since the original problem with floppys and CDs now "works for me" on 3.2 BRANCH, I am closing this as WFM. I hope that this is OK with everyone. If not, you have my e-mail address. -- JRT
The sidebar problem, which isn't confined to just the sidebar, has been reported as bug #73927. If anybody has any further comments to that problem, please add them there. -- JRT
Same problem with a digital camera using KDE 3.2.0 RC1. The bug is even bigger because of the hidden preloaded instances of Konqueror 3.2. With CDs no problem.
Since I do not have any mountable devices other than CD-ROM and floppys (which IIUC now work correctly under 3.2.0 -- at least they work for me), I am not able to be of further help testing this. Is someone that has the 3.2 release installed would please post specific test cases, it would be appreciated. -- JRT
I have an ASUS DVD+-R/+-RW as /dev/dvdrecorder linked to /dev/hdd and an Phillips CD-r/rw as /dev/cdrecorder linked to /dev/sd0. I am using KDE 3.2 Suse rpms on SuSE 9.0. If I mount either drive with Konqi by clicking the desktop icons, then unmout via the icon right-click menu, and then eject via the icon right-click menu, the eject fails. I cannot eject from the physical button on the drive. Even bypassing kdeeject, and going directly to the eject command does not eject it. I wrote a quick script that calls eject, then loops until it actually ejects. The time from the first eject command until a successful eject varies from 88 seconds to 491 seconds (over 8 friggin minutes!) with a sample size of five tests. Mounting, unmounting, and ejecting from a shell (without using Konqi at all) works just fine. It seems that a kio_audiocd slave is holding up progess. Manually killing it lets the eject command work immediately. The cd I was using was _not_ an audio cd, but SuSE 9.0 Pro install disk 1. Here is my evidence for this conclusion: mark@Liberty1:/boot/grub> lsof /dev/dvdrecorder COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME kdeinit 3112 mark 133r DIR 22,64 4096 59392 /media/dvdrecorder mark@Liberty1:/boot/grub> lsof /dev/dvdrecorder COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME kdeinit 4546 mark 12r BLK 22,64 6409 /dev/hdd mark@Liberty1:/boot/grub> ps ax | grep 3112 3112 ? S 0:04 kdeinit: konqueror --preload 4559 pts/4 R 0:00 grep 3112 mark@Liberty1:/boot/grub> ps ax | grep 4546 4546 ? S 0:00 kdeinit: kio_audiocd audiocd /tmp/ksocket-mark/klauncherTZYQXa.slave-socket /tmp/ksocket-mark/konqueror8sembc.slave-socket 4562 pts/4 R 0:00 grep 4546 mark@Liberty1:/boot/grub> kill 4546 mark@Liberty1:/boot/grub> lsof /dev/dvdrecorder mark@Liberty1:/boot/grub> Please, please, please, kill this bug. Regards, Mark
I have just installed 3.2.2 with Slackware 9.1. The problem is still there... you can't eject a CD after opening it with Konq. One thing that does help is to set the number of loaded instances of Konq to zero. (Settings, Performance). This cuts down on the wait time before Kong releases the CD. Another thing that seems to work, but is a PITA, is to open a terminal, go to root, and do: mount /mnt/cdrom umount /mnt/cdrom eject -r cdrom (or /dev/cdrom or maybe leave it blank and just use r... I forget which works.) Browsing away from the open CD in Kong does NOT work for me. This is a MAJOR bug... indeed, it's a deal killer. It think it gives KDE a really "bad name." When people say that Linux is not "as good" as XP, and that open source software has as many bugs as closed source, this is the kind of thing that they point at. PLEASE FIX THIS ONE IF POSSIBLE. Thanks, Al
Agreed. This bug REMAINS in KDE 3.2.2-4, which is the version shipping with Fedora Core 2. I can not open a CD and then successfully ejecct it without either A) exiting KDE or B) somehow killing a (hidden) Konqueror instance. This is VERY unintuitive and will surely, as many people have said, turn new users off KDE very strongly.
This problem persists in KDE 3.2.1 as shipped with SuSE 9.1 In particular I have a problem unmounting an encrypted filesystem (which is a file mounted as loop-back). I unmount the encrypted filesystem before suspending the machine, but I do not find it reasonable to kill all konqueror instances before suspending (not having to do so is the whole point of suspending!). This is an extremely annoying bug and it has been around for ages. Any fix would be highly appreciated!
still valid as in 3.3 really annoying, can't eject a CD really hard to understand for non-unix users
I dont think this bug should be close
> really annoying, can't eject a CD > really hard to understand for non-unix users Hi, This bug was really annoying, but I've had no problems for quite some time now. Are you sure you are experiencing it? That is, simply not ejecting may not be a bug. For instance, if you have a Konsole or Konqueror open where the CD is mounted, or maybe are using some file in the CD, then it is not supposed to eject. This bug was about konqueror itself keeping the cdrom busy with no apparent motive... You can see what is keeping the cdrom busy using lsof | grep 'your device' e.g. lsof | grep cdrom lsof | grep cdrecorder ... Sorry if you already know all this stuff :) J.A.
running 3.3, all konsole and konqueror window close, I still experience it i have to kill fam and then its ok. but KDE Should make it as easy as my mother can use it like under windows, you press the button, it ejects like under mac, right click eject, it ejects none of this two works but the following usually works -> ALT-F2 (run) + eject /dev/cdrom
> i have to kill fam and then its ok. fam checks for changes in files, I think... so it depends on who's fault is it that fam is watching files in the cdrom > but KDE Should make it as easy as my mother can use it It's not really about KDE. > like under windows, you press the button, it ejects > like under mac, right click eject, it ejects > none of this two works Almost. It really should not eject if the device is being used, that can be very bad depending on what you are doing. Other than that, I think the 2nd works fine in most distros, and in some others (like SUSE 9.1) the 1st is supposed to work fine too. > -> ALT-F2 (run) + eject /dev/cdrom I think this should be equivalent to right click-> eject. Anyway, most of that doesn't really help this bug report ;) What is really needed is info about what's blocking your cdrom, in order to find out if it's KDEs fault, and therefore a KDE bug. J.A.
I closed this as WFM because it does work for me. If your are having a problem with unmounting CD-ROMs that is not the problem with the side bar: bug #73927, with KDE-3.3.0, or later, please advise me exactly how to reproduce the problem and I will be happy to reopen the bug. However, if I can't reproduce it, there is no way it is going to get fixed. If you are using an automounter, please make sure that it isn't causing the problem. -- JRT
well, its not about KDE specificaly, but I think most user would consider KDE's job to workaround system problem and make everything works. cupsd do the printing job, KDE make cups usable by anyone for my cdrom problem, I just tested again. I put a CD on, with a video file, I ran into the K menu to the quickbrowser, to the /mnt/cdrom when I got to /mnt, it took 30 secs before I see the content of /mnt during the mount process, my MP3 stop playing, mouse cursor freeze, everything seems dead... about 3 seconds later, all fine, and I get the menu. I go under /mnt/cdrom, I click on the video file kaffeine open and play the video. watch the video for a few minutes. stop the video, quit kaffeine by right cliking on the systray app -> quit fam is still running mjobin 2189 0.0 0.3 3512 1436 ? S 21:39 0:01 [fam] can't eject fuser on my cdrom device does not show anything I still can't press the eject button df does not show my cdrom as mounted /etc/mtab show a regular supermount entry, similar to fstab none /mnt/cdrom supermount ro,dev=/dev/hdc,fs=auto,--,iocharset=utf8 0 0 I run KDE Post 3.3 on Mandrake Linux release 9.1 (Bamboo) for i586 my automounter is supermount none /mnt/cdrom supermount dev=/dev/hdc,fs=auto,ro,--,iocharset=utf8 0 0 anything else you want to know ? my cdrom is not shown under devices:/ ioslave so I'm not where to RMB->eject
I'm still having similar problems with directories being watched by famd long after the konqueror window has been closed. Could this be related to the 'preload konqueror' speedup feature? (I have max 2 buffered instances set.)
Le 9 Novembre 2004 15:36, Gintautas Miliauskas a écrit : > ------- I'm still having similar problems with directories being watched by > famd long after the konqueror window has been closed. Could this be > related to the 'preload konqueror' speedup feature? (I have max 2 buffered > instances set.) I am sure it is. I saw something similar, where umounting a digital USB camera did not work after closing konqueror -- unless turning off the preload konqueror feature. Guillaume Pratte
Am Wednesday 10 November 2004 00:24 schrieb Guillaume Pratte: > I am sure it is. I saw something similar, where umounting a digital USB camera > did not work after closing konqueror -- unless turning off the preload > konqueror feature. Hmm, do you have a fuser output of the affected device? Greetings, Stephan
> I am sure it is. I saw something similar, where umounting a digital USB camera > did not work after closing konqueror -- unless turning off the preload > konqueror feature. Yes! disabling preloading apparently solved the problem on Sarge (konqi 3.2.2). fuser definitely shows that famd instance doesn't die when closing konqueror, unless preloading is disabled. I think I'll use this workaround for now :-)
> > I am sure it is. I saw something similar, where umounting a digital USB > > camera did not work after closing konqueror -- unless turning off the > > preload konqueror feature. > > Hmm, do you have a fuser output of the affected device? Sorry, I don't. It was not on my computer that I observed this phenomenon. Maybe David Morel could provide the output? By the way, I have an hypothesis on why this is happening. Maybe this preloading Konqueror feature works by hiding the last konqueror window instead of closing it. If it is so, then konqueror stays "inside" the last directory it was before it was hidden, thus occupying the device. It I'm right, then a very simple solution to this problem would be to have konqueror point at the root directory ("/") when it is hidden, thus liberating the mount point and making it possible to unmount the device. Guillaume Pratte
> It I'm right, then a very simple solution to this problem would be to have > konqueror point at the root directory ("/") when it is hidden, thus > liberating the mount point and making it possible to unmount the device. That's already the case. It's probably more complicated than that (libfam watches several directories on behalf of konqueror, not just the $PWD).
DM and GP, did you make use of the navigation panel? I have noticed that it does not release its subdirectory/file watches when collapsed (comment #96). Other cases works for me. [And closing/hiding? the navigation panel does not help. Not even removing the Devices tab helps...] Question is - should the bug be reopened or should I create a new one?
Le 12 Novembre 2004 19:55, Roger Larsson a écrit : > DM and GP, did you make use of the navigation panel? Not that I remember of. Maybe DM can confirm / infirm? G.
This bug is definitely not resolved. It reappeared in KDE/Konqueror 3.3.1 and it is Konqeuror specific. No fam running, no other app doing this. Reproducible: always Steps - via Konsole: lsof |grep /mnt/cards/smediaXD/ ==> no output mount /mnt/cards/smediaXD konqueror /mnt/cards/smediaXD choose "root-dir" as the layout of left pane browse-into dir structure of the respective device browse out-of dir structure of the respective device (even collapse the dir in left pane) and open another directory i.e. homedir umount /mnt/cards/smediaXD (in another Konsole session) ==> not possible, device being used lsof |grep /mnt/cards/smediaXD ==> see below konqueror 8609 testman 128r DIR 8,65 16384 279 /mnt/cards/smediaXD/dcim konqueror 8609 testman 135r DIR 8,65 16384 1 /mnt/cards/smediaXD close konqueror window completely (either CTRL+C or X icon) lsof |grep /mnt/cards/smediaXD/ ==> no output umount /mnt/cards/smediaXD (in another Konsole session) ==> works like a charm Other comments: I'm experiencing this beahavior regardless of the type of device being mounted/unmounted. The one used in this test was a flash card. The core reason is IMO some kind of crippled history keeping in the directory structure (aka "root-dir") layout of Konqueror's left pane.
The problem I described is reported as bug 87326. Check it out for furter info.
>Le 12 Novembre 2004 19:55, Roger Larsson a écrit : >> DM and GP, did you make use of the navigation panel? > >Not that I remember of. Maybe DM can confirm / infirm? Navigation what? No, I nearly never use it. The behaviour I experience is most likely not related to it. I also noticed something strange once, maybe related, i don't know (didn't have time for further enquiries, my boss is kicking my ass every other minute these days, I'm'bout 2 weeks behind schedule): Opened konq window on a flash usb drive, opened text preview in konq window (with advanced editor kpart), closed it, and again unable to umount drive. Seems the kpart kept some sort cache in /tmp & kept the file open. Is it a problem with konq not closing properly its children?
Again! With no history or any other panel, and no preloaded konqueror instance. Try to open a -wrongly- mounted floppy (basedir mode 700), konqueror denies access to directory, fair enough. I close konqueror window, try to unmount device, and can't (device busy). Then: root@morel:~ # lsof /media/floppy/ COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME famd 2673 davemo 271r DIR 2,0 7168 1 /media/floppy/ This is on Debian sarge.
Sorry everyone, I forgot fuser output: root@morel:~ # fuser /media/floppy/ /media/floppy/: 2673
Navigation panel (the key "F9" toggles its use)
Nope, read my previous posts
I still have this bug. Debian Sarge KDE 3.3.1 Konqueror 3.3.1
The bug has never disapear for me... KDE/Konquror 3.3.2 Debian Sid up to date Even closing all konqueror windows doesn't allow me to unmount. I have to restart famd.
I don't get this : This bug is 3 (!!!!!) years old ! On my project, I dont leave a bug open for 3 years. I am on gentoo, with KDE 3.3.2 It 'seems' that I did not have the problem with previous KDE versions (3.2 ?) But anyway it is still there : when I close a konqueror window after having browsed the cdrom, I can't eject because there is a remnant konqueror task (though no window) that is keeping the mounted point busy. PLEASE GUYS PAY ATTENTION TO THIS ISSUE.
> This bug is 3 (!!!!!) years old ! On my project, I dont leave a bug open for 3 years. > > I am on gentoo, with KDE 3.3.2 > It 'seems' that I did not have the problem with previous KDE versions (3.2 ?) How can you claim the bug is 3 years old if 3.2 didn't have it?? The same symptom can be caused by multiple underlying issues - we fixed a few, but it's apparent that some other underlying issue remains. > But anyway it is still there : > when I close a konqueror window after having browsed the cdrom, I can't eject because there is a remnant konqueror task (though no window) that is keeping the mounted point busy. Yes, the question is: which part of kde exactly keeps it busy. It could be the file ioslave, the konq process itself, the preview ioslave, etc. If you don't investigate e.g. with fuser, we can't fix it. > PLEASE GUYS PAY ATTENTION TO THIS ISSUE. PLEASE DON'T SHOUT, IT DOESN'T IMPROVE MY MOOD TO FIX YOUR BUGS
> Yes, the question is: which part of kde exactly keeps it busy. It could be > the file ioslave, the konq process itself, the preview ioslave, etc. If you > don't investigate e.g. with fuser, we can't fix it. i had a quick look at the code (just because this bug occasionally bears its ugly face at me, and that it would be nice to get it well and truly rid). it would seem that on the close event of a konqui window, the window and all viws are hidden (if it is told to be preloaded?). perhaps a simple fix might be to direct all views to another neutral location after hiding, say somewhere like about:blank. any filesystem locks held on the previous (potentially mounted) location would definitely be in error since konqui should no longer have any reason, past or present, to hold that location. is it worth trying this? gav
Gav, sounds like a very reasonable approach.
On Thursday 10 February 2005 16:00, Gav Wood wrote: > it would seem that on the close event of a konqui window, the window and all > viws are hidden (if it is told to be preloaded?). perhaps a simple fix might > be to direct all views to another neutral location after hiding, say > somewhere like about:blank. Hmm, I thought this was already the case. I see that it's not. Can you check if this patch helps? It implements your suggestion (loading about:blank, to make sure any KDirLister is deleted etc.). Maybe a chdir("/") is necessary too - I was quite sure we had it, but I can't find it... Lubos? Created an attachment (id=9536) konq_mainwindow.cc.diff
I think there was a chdir() call that had to be removed since it made all the file dialogs start in / and not ~ initially. May be it just needs to be a chdir to a home directory or such, though.
> Maybe a chdir("/") is necessary too - I was quite sure we had it, but I > can't find it... Lubos? Afaik its reverted because KFileDialog would always start at "/" instead of last opened directory.
> May be it just needs to be a chdir to a home directory or such, though. Yes, sounds like it should be a chdir to KGlobalSettings::documentPath() then [which defaults to $HOME]. Can someone confirm that a chdir("/") helps? Then I'll add it with the right path.
> Can you check if this patch helps? It implements your suggestion (loading > about:blank, to make sure any KDirLister is deleted etc.). seems to work ok with the patch, however the bug is surprisingly slippery and i wouldn't like to confirm it has fixed it for all situations. that said, it should be committed asap, since it cant really do anything but help. gav
Actually Lubos pointed out that clearing the views is already done, by the window->viewManager()->clear(); in KonqMainWindow::setPreloadedWindow. So any directory view is already cleared, going to about: doesn't change anything. We talked about the chdir and a QDir::setCurrent(QDir::homeDirPath()) would be a good thing to do, but that's slightly unrelated since it wasn't done in that patch either.
Has anyone been able to consistently reproduce the problem? Except for the specific problem which I started the separate bug #73927 for, I am not able to reproduce the problem. I note that I do not use an automounter and suspect that using one might be part of the problem. -- JRT
other possible cause for the problem: when a fam watch is setup on a directory (say /mnt) famd actually watches /mnt/* # fuser /mnt/cdrom $ konqueror /mnt kio (KDirWatch): Added Dir /mnt [KDirWatch-1] kio (KDirWatch): Setup FAM (Req 1) for /mnt # fuser /mnt/cdrom /mnt/cdrom: 15392 # umount /mnt/cdrom umount: /mnt/cdrom: périphérique occupé since /mnt is not manually mounted, the watch is never removed: <goes up one dir>: kio (KDirListerCache): [void KDirListerCache::forgetDirs(KDirLister*, const KURL&, bool)] 0x834bdb8 item moved into cache: file:///mnt kio (KDirListerCache): listDir: Entry not in cache or reloaded: file:/// kio (KDirWatch): Added Dir / [KDirWatch-1] kio (KDirWatch): Setup FAM (Req 5) for / # fuser /mnt/cdrom /mnt/cdrom: 15392 this does not happen if I go straight to /mnt/cdrom, then switch to e.g /home: kio (KDirWatch): Added Dir /mnt/cdrom [KDirWatch-1] kio (KDirWatch): Setup FAM (Req 1) for /mnt/cdrom <go to /home> kio (KDirWatch): Cancelled FAM (Req 1) for /mnt/cdrom kio (KDirWatch): Removed Dir /mnt/cdrom [KDirWatch-1] # fuser /mnt/cdrom # umount /mnt/cdrom
James Richard Tyrer a écrit, le 10.02.2005 19:09 : > Has anyone been able to consistently reproduce the problem? Yes. Without any automount, on Debian Sid. $ konqueror --version Qt: 3.3.3 KDE: 3.3.2 Konqueror: 3.3.2 Steps: 1: Mount the /cdrom 2: Open Konqueror in your home directory, with the folder panel. 3: Try to un-mount. It fails. But i can assure that it is always the case. Closing the konqueror window allows me to unmount..
Now using Debian konqueror 3.3.1-4 without kernel automount. I *used to* consistently get the following problem: With "Maximum number of instances kept preloaded" set to 1 (Control Centre / KDE Components / KDE Performance). [Setting it to 0 got rid of the bug]: * Open Konqueror by clicking on camera icon (USB mass storage disk). This mounts the device. * Close Konqueror window. * Try to unmount by right-mouse-menu on the camera icon. * Get "unmount: /camera: device is busy" * [Killing the preloaded konqueror process would always allow me to unmount it.] * [I never had this problem on a CD-Rom device for some reason.] I got it the first time I tried today (as described above) but now I can't reproduce it. David Faure please make the change you describe.
> * [I never had this problem on a CD-Rom device for some reason.] My guess is that this is because of the thumbnails kioslave, which opens the picture on the camera, and that it's not related to Konqueror's preloading at all. But as long as we're only guessing...
OK, here is a way to consistently reproduce the problem on a CD-ROM drive (in Debian konqueror 3.3.1-4): Preconditions: * Set "Maximum number of instances kept preloaded" to 1 (Control Centre / KDE Components / KDE Performance). [Setting it to 0 gets rid of the bug]: * Ensure no preloaded konqueror exists: kill all konqueror processes. * Ensure CD-ROM drive is unmounted. Do this: * Click on CD-ROM icon on desktop. Konqueror window comes up. * In the tree view on the left pane, open "Devices" (click +) then inside that, open "CD-ROM" (click +). * Open something else in the tree view, e.g. "Hard Disc (hda6) [/]" by clicking on it - not its + button, so that the list of files on your CD ROM no longer appears in the right pane. * Close Konqueror window. (Now no konqueror windows are visible.) * Try to unmount CD-ROM from right-mouse-button menu on desktop CD-ROM icon. * I now get this error "umount: /cdrom0: device is busy". * [Kill the "preloaded" Konqueror process, then retry unmount: Unmount is then successful.] When I did this slowly (while writing the above) it did not fail, but it fails consistently otherwise. Steve
> when a fam watch is setup on a directory (say /mnt) > famd actually watches /mnt/* Good catch. I'll make a patch for that one.
Re: comment #167 Yes, that is correct. However, is this the general issue or is it a specific issue related to bug #73927? -- JRT
CVS commit by faure: Yet another fix for #37780 (unable to unmount device): don't keep a watch on /mnt, it makes FAM keep hand on /mnt/cdrom, and then we can't unmount it. Thanks to Germain Garand for solving the puzzle. I don't dare closing the bug yet, but things seem to work well here. Please test. CCBUG: 37780 M +23 -4 kdirlister.cpp 1.183 --- kdelibs/kio/kio/kdirlister.cpp #1.182:1.183 @@ -478,9 +478,28 @@ void KDirListerCache::forgetDirs( KDirLi itemsCached.insert( urlStr, item ); // TODO: may return false!! - // watch cached directories if not manually mounted, otherwise set to "dirty" - if ( !KIO::manually_mounted( item->url.directory( false ) + item->url.fileName() ) ) - item->incAutoUpdate(); + // Should we forget the dir for good, or keep a watch on it? + // Generally keep a watch, except when it would prevent + // unmounting a removable device (#37780) + const bool isLocal = item->url.isLocalFile(); + const bool isManuallyMounted = isLocal && KIO::manually_mounted( item->url.path() ); + bool containsManuallyMounted = false; + if ( !isManuallyMounted && item->lstItems && isLocal ) { + // Look for a manually-mounted directory inside + // If there's one, we can't keep a watch either, FAM would prevent unmounting the CDROM + // I hope this isn't too slow (manually_mounted caches the last device so most + // of the time this is just a stat per subdir) + KFileItemListIterator kit( *item->lstItems ); + for ( ; kit.current() && !containsManuallyMounted; ++kit ) + if ( (*kit)->isDir() && KIO::manually_mounted( (*kit)->url().path() ) ) + containsManuallyMounted = true; + } + if ( isManuallyMounted || containsManuallyMounted ) { + kdDebug(7004) << "Not adding a watch on " << item->url << " because it " << + ( isManuallyMounted ? "is manually mounted" : "contains a manually mounted subdir" ) + << endl; + item->complete = false; // set to "dirty" + } else - item->complete = false; + item->incAutoUpdate(); // keep watch } else
I was one of the reporters of this bug (Bug 53087). The bug 53087 was marked as duplicated of this bug. Well, I found in the discussion of this bug that this only happens when you use the dnotify as backend to scan directories. If you use fam, this bug disappers. And this is what makes some have the bug and some not. This is a bug of dnotify. I'm using the kde since 3.2.x without problems. When I switched to fam, this bug disappears. All times that I try to use dnotify, this bug appears. It seems that dnotify keeps the directory open until the process is closed, preventing the correct unmounting of device. This not happens with the fam. The fix of this bug is to use fam everytime. Someone close this bug and makes a advice to use fam, because dnotify is buggy.
I can't reproduce this here. I'm using gentoo 2004.3, fam 2.7.0, starting famd in boot (rc-update add famd default), kde 3.3.2, qt 3.3.3. If I kill famd, the bug appears. If I start famd again, the bug disappears. I open a konqueror window in /mnt/cdrom and unmounts the /mnt/cdrom without trouble.
Hi everybody, using KDE 3.3.2, with FAM, I have a couple SMB shares mounted under /home (group directories etc from a Samba server). Even without any Konq instances running, I cannot umount them, because fam processes are "watching" all these directories and there is no (obvious) way to end these famd processes (other than 'kill <PID>'). Other than that, I use Konq preloading under SuSE 9.1 (with submount/subfs) and I haven't had the problem of not being able to eject a CD (which happens with subfs when a process still has files open underneath the mount point) for ages. Thanks, Jens
If it can help, I extracted this from kernel traffic #264 (http://www.kerneltraffic.org/kernel-traffic/kt20040625_264.html): "dnotify needs a file to be kept open on the device, causing problems during unmount". This is from ubuntu forums (http://ubuntuforums.org/archive/index.php/t-1159.html): "fam uses a kernel feature called dnotify, which is what causes this problem. There is a new replacement, called inotify, which we will have in HoaryHedgehog, along with a new fam replacement called gamin." From RedHat bugzilla (https://www.redhat.com/archives/fedora-test-list/2004-July/msg00709.html): "This is a complicated issue. Fam is often blamed because some app has a monitor open on some directory, but killing that app makes fam release the monitor. Such a problem is really not the fault of fam. However, there *is* a bug in the dnotify code in fam that sometimes made it forget that it had a monitor on a directory, so you had to kill fam itself (as root) to fix it. This is really bad, but I finally sat down and tracked down the bug. The fix is in fam-2.6.10-1, which will be in rawhide shortly. No doubt there are still ways to get fam to lock unmounts, however thats not the fault of fam anymore, so i'm closing this bug." There's a patch in gentoo that can solve this problem. I think so because I don't have this problem. I'm uploading the patch to people test it. This patch is applied against fam, not kde!! Please, give me some feedback.
Created attachment 9656 [details] patch to be applied in fam This patch is to be applied in fam. This bug seems to be a fam/dnotify bug. I hope that this patch can solve the problem.
A last reading for all. http://bugs.gentoo.org/show_bug.cgi?id=43027 I hope that this can finally close this 3-years bug.
Perhaps we need to ask what version of FAM users are using and what configuration, patch, etc.. I have FAM-2.7.0 and am using this patch: http://www.linuxfromscratch.org/blfs/downloads/svn/fam-2.7.0-dnotify-1.patch which requires running: "autoreconf" after patching. I configured KDELibs with: "--enable-dnotify". -- JRT
Why is this considered "resolved", this is still a problem. If you mount a cdrom under /mnt/cdrom, use konqueror to view the contents, then you can't unmount the cdrom unitl you completely close konqueror. This has been a problem with every version of KDE I have used (starting with 3). Currenty I use 3.3.2. liquidcable
Re: Comment #168 It shouldn't be a problem under 3.3.2. If you want, you can post a test case describing exactly how to reproduce the problem. However, since the problem, AFAIK, has been resolved in the 3.4.0 Release candidate, it is resolved. -- JRT