linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Samuel Thibault <Samuel.Thibault@ens-lyon.fr>
To: Jens Axboe <axboe@suse.de>
Cc: "Sébastien Hinderer" <Sebastien.Hinderer@libertysurf.fr>,
	linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: Impossible to read files from a CD-Rom
Date: Fri, 12 Sep 2003 11:58:26 +0200	[thread overview]
Message-ID: <20030912095825.GB568@bouh.residence.ens-lyon.fr> (raw)
In-Reply-To: <20030912065116.GA16813@suse.de>

Le ven 12 sep 2003 08:51:16 GMT, Jens Axboe a tapoté sur son clavier :
> On Mon, Sep 08 2003, Samuel Thibault wrote:
> > The solution would be to return an error if 
> > cgc.buflen != sizeof(track_information) after the truncation to
> > sizeof(track_information), so that cdrom_get_last_written() will
> > correctly fail, and make cdrom_read_toc() use cdrom_read_capacity()
> > instead, which gives the correct answer.
> 
> It isn't that easy, if that were the case there would be no need for the
> above code would there?
> 
> This basically boils down to a typical problem with CDROM/DVD drives -
> some specific structure may vary a little in size depending on when in
> the spec cycle they were implemented. Some drives barf if you try and
> read to much, some when you read too little. So the approach that
> typically works the best is to just read the very first of the
> structure, check the length, and issue a read for the complete data.

This is fine. Another solution would be that cdrom_get_track_info returns
the actual amount of data that was read, so that the caller may check
that the field it needs was really filled up.

> I'd be more interested in fixing the real bug: why does your drive
> return zero length, and only sporadically?

This we don't know, and I don't think we may do much about it. The cdrom
drive is a Dell one, connected to a dell laptop. They don't come from
the same laptop package at first, but it should still work (or linux may
try to work it around).

The very funny thing about it is that with 2.4 there was no problem
merely because it happened that the not filled up track_size field
already had a very big value, so that linux would think the cd is
actually very big and let i/o go...

Regards,
Samuel Thibault

  reply	other threads:[~2003-09-12  9:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-18 16:35 PROBLEM: Impossible to read files from a CD-Rom Sébastien Hinderer
2003-09-08 15:28 ` Samuel Thibault
2003-09-12  6:51   ` Jens Axboe
2003-09-12  9:58     ` Samuel Thibault [this message]
2003-10-08 20:32       ` Samuel Thibault
2003-09-13  7:34     ` Daniel Pittman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030912095825.GB568@bouh.residence.ens-lyon.fr \
    --to=samuel.thibault@ens-lyon.fr \
    --cc=Sebastien.Hinderer@libertysurf.fr \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=samuel.thibault@fnac.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).