public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: lseek() on an iso9660 file
Date: Wed, 9 Jan 2002 09:24:56 +0100 (MET)	[thread overview]
Message-ID: <200201090824.JAA25149@cave.bitwizard.nl> (raw)
In-Reply-To: <a1cn1j$sev$1@cesium.transmeta.com> from "H. Peter Anvin" at "Jan 7, 2002 09:48:35 am"

H. Peter Anvin wrote:
> Followup to:  <Pine.LNX.3.95.1020107091316.18091A-100000@chaos.analogic.com>
> By author:    "Richard B. Johnson" <root@chaos.analogic.com>
> In newsgroup: linux.dev.kernel
> > 
> > Using Linux 2.4.1 I discovered a problem with lseek on CDROM files
> > (iso9660). I just installed 2.4.17 and found the same problem.
> > 
> > The problem:
> > 
> > (1) A portion of the file, existing on a CDROM,  is read and its the
> >     contents are written to an output file on writable media.
> > 
> > (2) The current input file-position is obtained using
> >     pos = lseek(fd, 0, SEEK_CUR); The value returned is exactly
> >     the expected value.
> > 
> > (3) The rest of the CDROM file is read and written to the output file.
> > 
> > (4) The file-position of the CDROM file is then set back to the saved
> >     position using lseek(fd, pos, SEEK_SET); The value returned is
> >     exactly the expected value.
> > 
> > (5) The CDROM file is then read and its contents are observed to be
> >     scrambled in some strange manner in which word-length groups of
> >     bytes from near the end of the file are interleaved with the
> >     correct bytes. Basically, the file ends up being about twice
> >     as long as the original, with every-other two-byte interval
> >     being filled with bytes from near the end of the file.
> > 
> 
> a) How long is the file?
> b) What is the offset?
> c) What particular iso9660 options (RockRidge, Joliet, zisofs...)
>    does your disk use?
> d) Mount options?
> 
> This seems to be a rather serious bug, so I'd like to get to the
> bottom with it.

My questions would be: "What hardware?".

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

      parent reply	other threads:[~2002-01-09  8:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-07 14:18 lseek() on an iso9660 file Richard B. Johnson
2002-01-07 17:48 ` H. Peter Anvin
2002-01-07 18:22   ` Richard B. Johnson
2002-01-09  8:24   ` Rogier Wolff [this message]

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=200201090824.JAA25149@cave.bitwizard.nl \
    --to=r.e.wolff@bitwizard.nl \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /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