This message is from the T13 list server.
> From: Mike Berhan [mailto:[EMAIL PROTECTED]] > CDBs interpreted differently by different vendors, ... Yes. If we have transport that works only when the host has correctly predicted how many bytes the device will ask to copy In or Out, an app can't be written to work (with commands or) devices never seen in test. Some devices will ask to copy less than expected, others more. How many bytes a Cdb moves is complex, state-dependent, not clearly and fully specified, thus de facto vendor-dependent. This is not a theoretical problem. This is real. For instance, transport robust enough to copy everything that fits before freaking out because the drive unexpectedly wants to copy more is necessary for Linux `cdrecord` (popular there like Nero on Windows) to work with certain devices. I'm told some devices provide only enough bytes of a ModeSense header to express the idea of disk not present, others always provide the whole header. The host never succeeds in trying to please everyone all the time. (The merely paper, merely public standard says both devices are wrong.) > isn't always reliable to depend on the header length Yes, additionalLength fields are commonly zeroed, rather than set correctly. > Solution? Easy enough, just zero out > your buffer before sending the command Zero usually works, sometimes some other filler works better. Appropriate filler solves only the case of a device cutting a copy In unexpectedly short. That case is just the most common of the ten cases solved in SCSI-over-USB. (SCSI-over-USB lists thirteen cases: three agreements and ten disagreements. The three agreements are to copy No data, to copy a byte count of data In, and to copy a byte count of data Out.) > Knowing the exact # of bytes transferred > isn't a necessity, just something nice to > have. I'm not sure I know what this means. Agreed, millions of ATAPI devices ship now with the standards as they are and they work well enough to sell, so in some sense nothing necessary can be lacking. For example, ATAPI op x25 Read Capacity isn't a "necessity". With host & devices that correctly handle read errors, we could ask the host to binary search Lba space for readable Lba's, and quickly derive the maxLba that way. But to duck that work on both sides, we define op x25 Read Capacity. Having a bus trace show how many bytes the host or the device asked to copy which way is a first step towards believing they agreed over how many bytes were copied which way, and that agreement forms a significant part of reliable compatibility ... a part that t13 could improve. How can it be that I appear insane, when I say this? Curiously yours in breathtaking ignorance, Pat LaVarre
