[lkml]   [2007]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: iso9660 vs udf
On Wed, Sep 19, 2007 at 03:23:27PM +0200, Karel Zak wrote:
> On Sat, Sep 15, 2007 at 11:49:31PM +0200, Andries E. Brouwer wrote:
> > What goes wrong on the mount side is that when it hesitates between
> > iso9660 and udf it decides for udf when seeing "NSR02".
> > Maybe the heuristics in mount should be tuned.
> Also try:
> # blkid -c /dev/null /dev/cdrom

# blkid -c /dev/null /dev/hdc
/dev/hdc: TYPE="udf"

> # /lib/udev/vol_id /dev/cdrom

# /sbin/vol_id /dev/hdc

> Maybe vol_id provides better information -- the udf/iso code in
> libblkid seems poorer that in libvolume_id.

I think the blkid code started out as a copy of the code in mount(8),
but since then they may have developed independently.

Anyway, mount, blkid, vol_id all think that they see udf.
But the kernel cannot handle this type of udf.

> I'd like to see the CD image (or at least first 2Mb).

Ha, I hoped that someone would say that.
(But do you still want it if I say that it is mostly
a kernel problem?)

By the way, unfortunately a CD image does not work quite the same
as the real thing.

In udf/lowlevel.c you can read

unsigned int
udf_get_last_session(struct super_block *sb) {
i = ioctl_by_bdev(bdev, CDROMMULTISESSION, ...

and this ioctl will succeed on a CDROM, but fail on a loop device. Ach.

Now what goes wrong? In udf/inode.c/udf_current_aext there is support
for allocation types ICBTAG_FLAG_AD_SHORT (0) and ICBTAG_FLAG_AD_LONG (1)
and for no other types. However, ECMA 167 writes (in 14.6.8):

0-2 Shall be interpreted as a 3-bit unsigned binary number as follows.
The value 0 shall mean that Short Allocation Descriptors are used.
The value 1 shall mean that Long Allocation Descriptors are used.
The value 2 shall mean that Extended Allocation Descriptors are used.
The value 3 shall mean that the file shall be treated as though
it had exactly one allocation descriptor describing an extent
which starts with the first byte of the Allocation Descriptors field
and has a length, in bytes, recorded in the Length of Allocation
Descriptors field.
The values of 4-7 are reserved for future standardisation.

and this particular CD-ROM uses type 3.
So, I guess udf_current_aext() must be updated a bit.


[will send you a bzip2'd copy of the start of the CD-ROM separately]

> Karel Zak <>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-09-19 21:39    [W:0.070 / U:1.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site