Version: 0.11.18 (using KDE 3.3.2, compiled sources) Compiler: gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk) OS: Linux (i686) release 2.6.10 Situation is like this: * One CD-Writer device * I have a collection of audio files in a data CD (mp3's ogg etc) * Want to burn audio CD from some files in that CD (without copy to HD) When k3b ends decoding all files it displays a popup that says that no CDR available with option to eject an load device. So far so good. When I click on eject, insert an empty CDR and click "load" nothing happens until a timeout. I guess the reason is that the data CD is still mounted. So the "eject" command justs ejects the data CD without an appropriate umount. IMO there is a need for test if the device (e.g. /dev/hdc) is mounted and umount it if needed. Must take into consideration automount daemons (in fstab) - if so, I guess umount is not needed Thanks
it is normally not possible to eject a media without unmounting it and even if so; k3b does not care about the mounting state of a media. this has to do with somthing else. Does it still happen?
I experienced a similar issue today with k3b 0.12.3. I created an audio CD from MP3 files on a CD-R, and I placed the CD-R in my CD writer. I had On-the-fly turned off. The decoding process worked normally, but when k3b asked me to insert the blank CD-R, I couldn't, because the Eject button didn't do anything. I couldn't unmount or eject the MP3 CD from a terminal window either, because the filesystem was busy (apparently because k3b was holding the files on the disc open). After I cancelled the burning process, I *still* couldn't eject the CD until I had completely exited k3b. So I had to restart k3b, insert the MP3 CD in different drive from the CD Writer, and start over. This was with automounting/submounting turned off, on SuSE 9.1 with Linux kernel version 2.6.5. I haven't had problems with merely copying an audio CD using the same drive, though. Apparently, making an audio CD with files from a data CD-ROM using the same drive creates the issue.
This could be one head of the "Eject-Hydra". Bug # 99327, Bug # 126167 and probably more.
Actually this is a problem with the kde filebrowser used in K3b which sometimes keeps a lock on the files it displays. A lazy unmount should work here. (umount -l) I don't think it can easily be solved in k3b.
*** Bug 126851 has been marked as a duplicate of this bug. ***
This should be fixed in the svn now as K3b unmounts before ejecting and supports all the unmounting variants (plain umount, pmount, KIO::unmount, and HAL::unmount)
Eyal, can you try to reproduce this in 0.12 or 1.0, please.
The unmount fix is not in 1.0pre2. It will be in 1.0beta1 (I hope to get it released in the next days...)
Closing as fixed as per comment 6
please test 1.0beta1