Bug 59603

Summary: mksisofs volset-seqno option makes kernel activate cruft option
Product: [Retired] Red Hat Linux Reporter: gsr.bugs
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:39:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch to avoid the wrong check of seqno field and thus be able to read CDs that are part of a volume set none

Description gsr.bugs 2002-02-11 02:38:24 UTC 
Description of Problem:
Linux ISO FS implementation does some checks and if something does
not look fine activates cruft mount option. And those checks are not
related to size problems, while the solution is cut file size. What
is more, I doubt the checks, or at least the one that causes my problem,
is right here (see around line 1251 of fs/isofs/inode.c, the check of
volume_seq_no).

Version-Release number of selected component (if applicable):


How Reproducible:
Create a CD (or just iso image, no need to waste CDRs) with mkisofs
and options -volset "string" -volset-size N -volset-seqno n, with
N>=n. If volset-seqno is not 0 or 1, Linux kernel activates the cruft
option and makes all files of 16MB or more unusable. IOW, it mixes
volume set with size handling. The right of things are OK, what is more
the CD #1 of the set if read without complains or problems, things
go wrong with 2 and others, but all are built with the same command,
except seqno parameter.

Steps to Reproduce:
1. Create the CDs images, for example say you want a set of 2 CDs.
2. Mount the ISO images, one by one.
3. Check the logs when mounting the number 1 and then check again for 2.

For extra pain, try to access files with size 16MB or more in the mounted
fs of ISO 2.

Actual Results:
Linux kernel complains, and uses a chainsaw solution, probably for a
imaginary problem. Logs report something like:
kernel: Warning: defective CD-ROM (volume sequence number 2). Enabling "cruft"
mount option.

Expected Results:
Follow ISO9660 standard and let people use the volume set fields to
store the right info. In worst case, check that seqno is not more than
size. But never take this field as base to make files unaccesible, the
solution is wrong and radical.

Additional Information:
I have been reading
http://www.y-adagio.com/public/standards/iso_cdromr/tocont.htm
ftp://ftp.ecma.ch/ecma-st/Ecma-119.pdf	
See page 3 of PDF for the description of volume and volume set (CD
and group of CDs is what I undersand, not multisessions). Page 8 for
more info about volume set.

I think I am doing things right, I have a big group of related files,
some of them bigger than 16MB, and I put them in a group of CDs cos
650MB is not enough. In addition to the feltmarker, I use the fields
in the ISO headers to note that the CDs are a group, so I can extract
the info later via computer, not human typing only. That way I can
read "2 of 3" with my eyes lookin the top face of CD or with a program
scanning the bottom face, as I need.

I could be reading the standard wrongly... but then mkisofs man page
needs to include a warning, cos that is the place from where I get
the idea of volume sets first. But I still think that the bug is
kernel level, not application allowing bad usage.

Thanks.
Comment 1 gsr.bugs 2002-02-12 01:37:19 UTC 
mkisofs maintainer Jvrt Schilling seems to agree:
http://www.mail-archive.com/cdwrite@other.debian.org/msg02725.html

Patch attached.

GSR
Comment 2 gsr.bugs 2002-02-12 01:39:13 UTC 
Created attachment 45346 [details]
Patch to avoid the wrong check of seqno field and thus be able to read CDs that are part of a volume set
Comment 3 Arjan van de Ven 2002-02-12 09:35:25 UTC 
I think you misread the code a bit. The comment says that it did NOT set the
global cruft option because -->otherwise<-- files would be limited to 16Mb :(
Comment 4 Arjan van de Ven 2002-02-12 09:55:59 UTC 
Doh I misread the code ;()
Comment 5 gsr.bugs 2002-02-12 19:49:37 UTC 
Yes, you did... the first time I read it, I did too. Then realized
the comment is something like "we are going to be cool and allow 0
but only 1 is valid". By spec any number is valid if less than set
size. It does not say anything about single CDs, so I guess it must
be left blank, which should be 0 (that could explain how many "illegal"
CDs they found when testing). In general the terms used and the
comments are, to say it without insult, funny.

I tried with CDs 1, 2 and 3 of a group of 3. Only in 1 I was able to
rightly access the files of 16MB or more, CDs 2 and 3 reported smaller
file sizes, and data was "damaged". That was the real life test. As
you can imagine, the CDs work OK with the patch applied, cos all the
three were created with the same command, except the seqno change.

I ended printing the PDF, and I am still trying to find what the hell
is a multi-volume CD. You can have volume sets, but CD, each CD, is a
volume alone. There is no multi volume CD in the spec, you will only
find volume set, defined as group of volumes (CDs) that carry a set of
files which contents are determined at the same time, like a full
monthly magazine with really high res photos could be, or maybe the full
dump of a library at a given day.

And volume set id, volume set size and volume set seq no are all hints
that data preparers can use when making groups of CD, like RH install
could do (instead of checking a file in CD, installer could just check
id and seq no). In the case of the mag, a robot CD would be able to
detect that a CD is not the right one, or in the case of the library,
the same thing (humans mixing parts of magazines or dumps, ie).

My best guess is that the coder mixed volume with partition or session.
A CD can have multiple partitions or sessions... but a volume == CD,
page 3, point 4.17. There is no multi volume CDs, and the more I read
inode.c, the more I am convinced that someone has got confused a lot
(maybe cos in other places, like Windows disks, you call volume to
partition, from what I remember about naming HD, the name used was
"volume label" and I had a single disk with multiple partitions, each
with its "volume label"... Linux too, tune2fs talks about labels).
Linux implentation used definitions from unknown place instead of
checking what the spec itself defines.

And about the spec, my best guess is that drafters wanted to make the
format for libraries and other places with lot of data (byt the time
PCs weere toys). Thus targeting a full automatic enviroment with tags
for every possible usage they could think of (preparer, copyright file,
expiration date... it has a lot, and I guess most CDs do no use them...
but that is quite different than call the ones that do "damaged" or "out
of spec").

Sorry for the rant. But I get pissed when something follows a spec
for something, but not for everything, including definitions.

BTW, the error exists in plain 2.4.17, so I guess RH72 has it too.

GSR
Comment 6 Arjan van de Ven 2002-02-19 11:15:41 UTC 
Fixed in my tree. Will build soon for rawhide etc
Comment 7 gsr.bugs 2002-06-28 20:59:49 UTC 
The bug is back in RH7.3, it complains about valid CDs and takes
the same radical measure of cutting the files.
Comment 8 Bugzilla owner 2004-09-30 15:39:22 UTC 
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/