On Thu, 2004-11-18 at 07:55 -0500, Alan Cox wrote: > Perhaps. The problem is that some of the other file system code looks > at the _end_ of the disk. Unfortunately CD-R doesn't have an "end" it > sort of tails out into no-mans land. Really? Because using the BLKGETSIZE64 ioctl() on the device file we get 667502592 for FC3-i386-gold-disc3 668524544 for FC3-i386-gold-disc2 Hmm; the ISO files are this size -rw-r--r-- 3 root root 668520448 Nov 3 17:07 FC3-i386-disc2.iso -rw-r--r-- 3 root root 667498496 Nov 3 17:08 FC3-i386-disc3.iso which, respectively, is exactly 4096 bytes (two blocks of 2k) less than what the ioctl() gives. I wonder why that is; maybe it's just a wild goose chase, just curious. > Most drives politely handle such > requests, some don't. The ide-scsi driver has the needed magic to work > around some of this, ide-cd lacks it. > > > The HAL fix I guess would be to only try iso9660/udf on CD-R/CD-RW media, Yeah, that would screw some other users though, e.g. people actually put HFS/HFS+ (Apple install media) and ext2 (e.g. DVD-RAM) on optical discs. I suppose a better fix is to only look for filesystems that doesn't require looking at the end of the disk. That would indeed also include HFS/HFS+ (superblock is at 0x0200 offset like ext3). Reason we look at the end of the disk is that it's smart to probe for RAID/LVM1/LVM2 (which has the superblock at the end of the disk) before anything else as we otherwise might have a false positive. Just think of the havoc that adding /dev/sda1 being a RAID mirror member and g-v-m mounting that because it was added to the /etc/fstab. That would not be nice. > but it might ultimately be better if we can fix it kernel side. > Yah. Is that hard, e.g. can it be done within a reasonable time frame? I'd hate to put yet another special case into hal to work around a kernel bug. Cheers, David