> Pardon my ignorance, but I would like to ask what is the commonly > practiced method of creating multi-volume disks.
You must be referring to "Volume Sequence Number" defined for ISO9660 data-set. I myself would first wonder how common is support for *accessing* of such multi-volume data-sets. Note that I'm not saying that I know answer to either question, but I won't be surprised if support for multi-volume *access* turns to be commonly poor. > That is, for instance > I need to burn a directory that has files whose combined size is, say > 12 GB. How would one go about creating multiple ISO9660 images from it > and then burning them on CD/DVDs. Is there a way that these images can > themselves keep track of information like their position in the > sequence, total number of images that constitute the complete dataset > etc. Once again you probably should first wonder if and how target OS can use this multi-volume field, because if it doesn't treat it in the way you expect it to, then figuring out how to create multi-volume data-set won't solve the problem. > Also, what if the things are complicated by the existence of one or > more files of size > 2GB. Is this a Linux only issue? Note that it's not an inherent Linux limitation, but Linux isofs implmentation issue. I mean you can access files larger than 2GB under Linux, but not those residing on ISO9660 volume. And the fact that Linux exhibits this deficiency doesn't mean that *all* other implementations are bug-free. I mean breaking 2GB limit is indeed a problem with Linux isofs implementation, but given this fact alone one can't tell that it's not a problem on some other given OS. > Is this an issue on 64 bit SGI IRIX systems? I don't think anybody would be able to answer this question definitely. The only way is to try... Keep in mind that in Linux it's rather "signed vs. unsigned" than "32- vs. 64-bit" issue. A.