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.
mkisofs maintainer Jvrt Schilling seems to agree: http://www.mail-archive.com/cdwrite@other.debian.org/msg02725.html Patch attached. GSR
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
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 :(
Doh I misread the code ;()
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
Fixed in my tree. Will build soon for rawhide etc
The bug is back in RH7.3, it complains about valid CDs and takes the same radical measure of cutting the files.
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/