Hi, i wrote: > > A workaround in K3b would be let it retry on error ENOMEDIUM for about > > 30 seconds and to only then give up.
Gene Heskett wrote: > That ought to be doable, but would that not delay the ready by banging on > the drive for a status report during that time? It only has so much cpu > power. No. The drive works on its own after the tray went in (e.g. because the kernel sent a START/STOP UNIT command). It inspects the medium solely controlled by its built-in firmware. The kernel or a burn program can only send a command TEST UNIT READY from time to time. The answer may be that it is indeed ready for work, or that it is still undecided, or that there is a problem like no medium or incompatible medium. Currently the kernel immediately indicates ENOMEDIUM to any userland attempt to open the device until finally the drive is done with inspecting the medium and found it acceptable. Up to 2008 the kernel rather waited a short while and repeated the test until the "still undecided" reply was gone or timeout occured. Only then it answered to the attempt to open the device from userland. (Exempted are open(2) calls with O_NONBLOCK/O_NDELAY which do not check for the drive status. They are for those who want contact to the drive, not to the medium on the first hand.) A problem with a waiting loop in K3b would appear if the medium vanishes between eject and re-load or has become incompatible by a drive mishap. In this case K3b would wait 30 seconds in vain and could still not decide whether the drive is stuck or the medium is gone. But normally, the medium should still be there and the drive should be able to decide within a due time that it is at least recognizable. K3b could try to be smart and send own TEST UNIT READY commands to the drive. It does more obtrusive things during its own media inspection. Have a nice day :) Thomas
