Alan Stern wrote: > On Fri, 6 Apr 2012, Norman Diamond wrote: [Alan Stern:] >>> However there's no question that other bridges having the same vendor, product, and revision ID values as yours _did_ report the drive capacity incorrectly; otherwise the quirk entry would not be there. What I'm not sure of is whether those bridges went on to crash as dramatically as yours. >> >> Except that mine doesn't crash when trying to read a nonexistent block, so the quirk handling still looks overly aggressive. > > You're not thinking about it the right way. If the quirk handling were any less agressive, it would fail to work entirely on some devices (those that crash when trying to access a nonexistent block). I see your point, regarding devices which differ from mine, and which possibly differ from the other user in 2004 since we don't really know the reason for his crash (he might have had a bad block at or near the end of his drive). > Such devices would not usable at all. We are already in that situation because of the decrement. If the drive was partitioned while the drive was internally installed on an ATA cable, then the decrement now interferes with the usability of the drive regardless of whether the USB bridge really does or doesn't have a bug. The current driver doesn't even give a chance. Also, if the drive was partitioned when using a known non-buggy bridge, then the same situation happens when using a bridge whose status is ambiguous because the driver does a decrement. > Besides, suppose this quirk entry were removed. What would happen with the other bridges with the same ID numbers that do not decrement the block count properly? Linux would try to access the nonexistent last block, and the access would fail. Perhaps no unplug and replug would be needed, but any data destined for that block would be lost. The present situation loses reads and writes of the last block when the last block DOES exist. >>>> This still makes me wonder why Windows is able to handle the same bridges. >>> >>> Probably because Windows does not try to read the last block, unless it is occupied by a file. >> >> I think Windows does. At least in some cases the last block of a partition contains structural information and can't be used for files. At least in some cases Windows reports a file system error if that block can't be accessed when trying to mount the partition. > > Not in any of the cases I have seen or heard of, but that isn't a very large sampling. I found the reason for this. In Windows 2000 and later, if Windows is creating the partitions, Windows deliberately avoids using the equivalent of 1 emulated IDE cylinder (16065 sectors), in case the user decides later to convert the drive from Windows basic format to Windows dynamic format. Vista and later avoid using some different amount but the effect in our case is the same. Windows doesn't try to use the last block in such cases. But Linux can. I connected the drive to a known good USB-to-IDE bridge and created an NTFS partition containing the last sector in the drive. Then I connected the drive to my Prolific bridge. Windows accessed the NTFS partition with no problem, including its last sector. But Linux gave an error. Linux DOES also access the NTFS partition, but Linux gives an error that it truncated the partition because the partition runs past the point where Linux thinks the drive ends, which is due to the decrement. > You'll get an error right away; the partition-table-reading code doesn't accept partitions that appear to extend past the end of the device. I got an error in the log as you said, visible with dmesg. But hal offered to mount the partition, and fdisk displays the partition. OK, after reporting things up to this point, let's try mounting the partition, but read-only... The mount command obeyed with no error message, and no further report to the log. The ls command displays the contents (only System Volume Information at the moment, because Windows XP likes to create restore points on USB drives). But we know that Linux is accessing a truncation of the partition. -- 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
