> >> I just did run a test that verifies that the 708 in fact returns 36 bytes. > >> So the problem is definitely caused by a Linux driver bug. > >> > >> I tend to believe that growisofs just does not check the SCSI status > >> byte > > >Quoting myself. "Under Linux kernel 2.4 growisofs counts on sr_mod to > >check the status byte." Clarifying note. Under 2.4 growisofs counts on > >sr_mod to check the status byte and terminate corresponding ioctl with > >error code. Does growisofs check for return value? Yes.
Further clarifying note. Under 2.4 growisofs uses programming interface which does not exposes SCSI status byte. Instead the status byte is examined by sr_mod and if found non-zero, corresponding ioctl is terminated with error code, which growisofs pays attention to. Growisofs remains perfectly aware of problems encountered by commands and acts accordingly. If it wasn't the case [either sr_mod didn't terminate ioctl with error or growisofs didn't pay attention to it], then recording wouldn't work at all. E.g. if it didn't pay attention to error code from the command in question, READ DISC INFORMATION, it would most likely try to pull information for non-existing track. If it didn't pay attention to error code from READ TRACK INFORMATION, it would try to start recording at invalid adress. If it then didn't pay attention to return code from WRITE commmand, user would not ever be able to mount the media. > Sorry, you repeat useless statements :-( Does anybody else feel that way? > The _only_ sense I can take out of your repeated try to avoid a clear answer > is: > > growisofs does _not_ check whether the status byte is != 0 > > So it is obvious that growisofs only works because it does not check whether > the command encountered a problem. No, it's not. A.
