Hi, > This is fair, back in the old days I recall setting a machine to burn a > disc then wandering off.
My incremental backup updates shortened from 3.5 minutes to about 1.5 minutes on the new machine. Nevertheless i have reason to go for a cup of tea because it is advisable to keep the hands off the keyboard during this time. Else i risk to get copies of files truncated or padded up with zeros, because their size changed between writing of directory record and writing of content. Not to speak of files which are being written while being copied to ISO. There i'd have race conditions on the content consistency. > buffer underrun. Let's hold a moment of silence for all the misburned CDs which fell victim to insufficient feeding speed. (This time ended for me in 2003 when my Yamaha burner died and i got a Lite-on with burn-proof feature.) > >> it discourages the tray's misuse by the illiterate (e.g. as a > >> carry handle or cup holder). > > So if not i can control a burner - who else would ? > we both know there *are* users that have been guilty of the *exact* crimes > that I've described. :-) Well, the cup holder was subject to an old joke out of the series "Duemmster Anzunehmender User" (= "Dumbest Credible User"). Together with application of Wite-Out to the screen and the mouse being clicked against the window after removing the flower pots from its sill. But i think all classic professional DAUs retired meanwhile. The new DAU uses iPhone and Facebook to shoot the own foot. > Is there a command that says 'retract tray after N seconds'? Not to my knowledge. I believe to know quite well the SCSI specs for optical drives (mainly MMC, but also SBC and SPC). > Clearly the firmware has decided that it should retract the drive > without there being a command being issued at that moment This is not proven yet. btrace(8) shows no SCSI command passing through the kernel. This is not the same as no SCSI command going through the SATA controller to the drive. The boot firmware could theoretically do it on its own. > > Even more strange, i had two incidents of unexpected eject > Not sure if it's worth switching the machine across to > sysvinit to rule out any systemd shenanigans? Any system service would have to use the kernel for sending SCSI commands (or causing SCSI commands to be sent). Yesterday, when i tested my growisofs proposal for Eike Lantzsch, the usual tray dance at the end was not out-in, but out-in-out. Another drive showed only the traditional out-in move. (growisofs re-loads the tray after burning in order to make buffered i/o aware of the new disc content. Else the next session could fail because mkisofs cannot read the newly written previous session. libburn does not re-load because it does not read via buffered i/o after writing via SG_IO, because i deem the tray dance physically dangerous, and because it won't work on laptop drives anyway. The user shall re-load before using the medium for mounting or other buffered i/o.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6201560348878944...@scdbackup.webframe.org
