Alan Stern wrote: > On Thu, 3 May 2012, Norman Diamond wrote: >>> It looks like the bridge is sending just the least-significant 32 bits >>> of the capacity. What it should have done is reply with 0xffffffff. >>> Then the kernel would know to try again with a READ CAPACITY(16) >>> command, which is capable of retrieving values larger than 32 bits. >> >> You are right, bridges' failures to reply with 0xffffffff are >> bridges' bugs. Obviously Windows proceeded to try a READ >> CAPACITY(16) regardless. > > Don't be so sure. I have seen reports from others indicating quite > clearly that Windows would believe a partition table even when it > contradicted a device's reported capacity. Yes, but Windows didn't see the entire asserted partition, Windows saw the reported size of the drive and the asserted size the partition and the accessible area of the partition. In the test mentioned here, Windows saw the entire drive size, which had to come from READ CAPACITY(16). As mentioned earlier in this thread, in an earlier test I had taken a drive that had an NTFS partition and had subsequently been DCO'ed down to a size that truncated the NTFS partition. Windows saw the drive's reported size, saw the partition table, and refused to mount the partition. In that situation the DCO had cut off part of the NTFS structure that is mirrored at the end of the partition so Windows knew that the partition was not properly accessible. I have another different bridge, incredibly stupidly convolutedly designed to break its eSATA capability but with working USB3 capability. When using that incredibly stupidly convolutedly broken eSATA capability, Windows did not see the entire drive size. Windows saw the partition table but could not access partitions that were located beyond the visible drive size. > For example, early card readers can handle SD cards but not SDHC. I can donate around 2 to you ^_^ > When an SDHC card is inserted in such a reader, the reported capacity is too small. I don't recall seeing that. I just recall that the card was inaccessible (in Windows). > Windows would nevertheless believe the partition information. Interestingly, > when the user would try to repartition the card, Windows would not > allow a new partition to exceed the reported capacity. I see that symptom in a different case. Some USB memory keys, even when not fraudulently reconfigured to report fraudulently large capacities for sale by thieves on eBay, were preformatted by vendors with FAT16 partitions slightly larger than the actual capability. Windows saw the actual size of the USB memory key, saw the partition table, and allowed the partition to be accessed as long as no operation hit a broken area. Since FAT16's structure doesn't need a few blocks mirrored at the end of the partition, this was usable. And exactly as you say, Windows would not allow repartitioning to extend past the end of the device, so Windows knew the capacity that the device was reporting. >> I hope old bridges that can't handle READ >> CAPACITY(16) at least avoid crashing when presented with that >> command, so a workaround could always send that command. Or a quirk >> could be added to say which bridges crash. If a bridge sends an >> ordinary rejection saying that it can't handle the command but >> doesn't crash, then there's no need to avoid the attempt. > > You can try sending the command yourself using sg_raw, to see how well > your bridges handle it. I think we have enough evidence that mine handle READ CAPACITY(16). For bridges older than mine, we don't even need to worry if they reject a READ CAPACITY(16) but survive to continue the kinds of operations they ordinarily perform; we only need to worry if they crash when commanded to READ CAPACITY(16). -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
