[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.023 / U:123.396 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site