On Friday 21 Mar 2003 2:33 pm, Richard Urwin wrote: > On Friday 21 Mar 2003 1:29 pm, Tom Brinkman wrote: > > On Thursday March 20 2003 05:16 pm, Richard Urwin wrote:
> I did open the CD in Konquerer immediately after the burn, just to make > sure the data was there. This time through I closed GCombust first. (And > closed konquerer before trying to eject, of course.) > I experience this open/fast close from time to time after browsing cds. It is clear that you must make abosolutely certain that no Konqueror windows are open before you try to eject. I think it would also mean that you must not be browsing the directory in a shell, either. Still there appear to be times when that isn't enough. Sometimes it sorts itself out after a while, but if it gets stuck, I generally log out, then in again. > > It's likely just coincidental that by the time you ran that > > command, whatever has holding on to the burner had released it. Next > > time try 'eject /dev/scd0' (or scd? depending on which ? your burner > > is). 'Course if you're burning as root (you shouldn't be) you'll need > > to run the eject command as root. > > $ eject /dev/scd0 # Came out, went back in again > $ sudo umount -l /mnt/cdrom2 > Password: > $ eject /dev/scd0 # Came out, stayed out > > While I grant that that sequence took thirty seconds or so, and things may > have changed between the two ejects, that was a lot less time than I took > fiddling with it last night. > > It stands to reason that the burner must lock the drive closed while the > burn is happening. I don't know how that happens. Even if it isn't a mount > it might still have a similar effect on the top level mount/umount/eject > functionality. > I don't burn from the command line. Both XCDRoast and K3b have a setting to eject on completion, and I always use that. Anne -- Registered Linux User No.293302
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
