Messages in this thread | | | Date | Thu, 13 Nov 2003 06:52:54 -0500 (EST) | From | Bill Davidsen <> | Subject | Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt |
| |
On Tue, 11 Nov 2003, Linus Torvalds wrote:
> > On Wed, 12 Nov 2003, Pascal Schmidt wrote: > > > > My guess would be that an MO drive needs a different way to find out > > the capacity than a CD-ROM. After all, when using ide-scsi, it is the > > sd driver and not sr that handles the drive. The rest of the problems > > could be due to the wrong capacity information? > > Yes. That would explain a lot. > > The ide-scsi thing never uses "cdrom_get_last_written" crud. It just uses > the regular READ_CAPACITY command (0x25). > > Which is what ide-cd.c will fall back to as well ("cdrom_read_capacity()") > but I think it should _start_ with that rather than fall back on it. > That's the simple case, after all.
Are there any cases when the last_written size is really what's wanted, rather than the capacity? Such as unclosed multi-session iso9660, ufs, or whatever else I'm ignoring? > > Does it work if you change the order of those two things in ide-cd.c (or > just remove the call to "cdrom_get_last_written()" entirely, so that it > always just does the sane thing).
For a read-only access, I think the size is what's written, while for writing it's the physical size, I think. Does it need to be as complex as having the order depend on the access mode? It seems that a size of zero is correct for a read access to an unwritten media.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |