lseek() on an iso9660 file

lseek() on an iso9660 file

[Richard B. Johnson]

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.

If I mount the CDROM using the loop device, i.e.,

		mount -o loop /dev/cdrom /mnt

... the problem does not exist.

However, the performance is poor when mounting through the loop
device so this is not a good "fix". It takes about 5 minutes to
copy a 50 megabyte file from the CDROM through the loop device
while it normally takes about 50 seconds using the SCSI CDROM
directly.

If I am not supposed to use lseek() on a file existing on an
iso9660 file-system, how is an application to "know" that the
file is not lseek() capable? I need a "quick-fix". One at the
application-level is fine.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: lseek() on an iso9660 file

[H. Peter Anvin]

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.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: lseek() on an iso9660 file

[Richard B. Johnson]

On 7 Jan 2002, 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?

The file is 43,814,956 bytes in length.

> b) What is the offset?

Both 36 and 44 bytes hurt.

> c) What particular iso9660 options (RockRidge, Joliet, zisofs...)
>    does your disk use?

RockRidge attributes created by:

if  ! test $1 ; then
    echo "Usage cp.iso <directory>"
    exit 1
fi
umount /mnt 2>/dev/null
DEV=`cdrecord -scanbus | grep ROM | cut -f2,2`
echo Using CD-ROM device, ${DEV}
echo Trying to erase the media
cdrecord dev=${DEV} blank=fast
echo Starting to write the media 
nice --18 mkisofs -L -l -R $1 | cdrecord -v fs=6m dev=${DEV} speed=4 -eject - 


> d) Mount options?
> 

Just what 'mount' finds:

mount /dev/cdrom /mnt

It gets "fixed" by doing:

mount -o loop /dev/cdrom /mnt

/dev/cdrom is a sym-link to /dev/scd0


> This seems to be a rather serious bug, so I'd like to get to the
> bottom with it.
> 

This showed up when trying to use a "wave-file-copy-truncation" routine
with the source file on a CDROM.

The source-code for these "wave-file" tools is:

	ftp://boneserver.analogic.com/pub/downloads/wave_tools.tar.gz

Broken windows users have to access as:

	ftp:/boneserver.analogic.com/pub/downloads/wave_tools.tar.gz
  or else windows adds ..//ftp/.., a known bug.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: lseek() on an iso9660 file

[Rogier Wolff]

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.