I've just gone through the process again. On Friday 21 Mar 2003 3:28 pm, Anne Wilson wrote: > 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.
This time I closed GCombust and ejected the CD before opening konquerer. Once from the button on the drive, once using eject. Both worked perfectly. Then I opened the CD using konquerer. No files. I then mounted the CD by hand (sudo mount /mnt/cdrom2.) The files appeared. Then I tried to eject the CD. No dice, the button is ignored and eject does the now-you-see-it-now-you-dont routine. I unmounted the CD by hand. The first time it refused "device is busy." But it had only just retracted, and the drive was probably reading the index. I waited a second or two and the second umount worked. This time I got everything working without the -l flag to umount, so that is probably a red herring. My guess is that a standard umount will work, so long as you give it a while after a failed eject. Supermount was enabled at all times. Conclusion: Burning CDs can confuse supermount. Expect to mount/umount by hand. Wait for the drive to finish following a failed eject. I have finished my backups for now. I'll leave it to others to determine if ejecting and reinserting the disk after burning but before trying to read it reduces problems. > > > 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. GCombust is GUI, and was installed with MDK9.0 XCDRoast did not seem to be able to construct a CD, just to copy one. I may be wrong. > > Anne -- Richard Urwin
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
