Re: [Bug-xorriso] bug with handling symbolic links?

[Thomas Schmitt]

Hi,

the problem is not specific to BTRFS. I can reproduce it
by an ISO generated from ext3.

The kernel obviously complains that a Rock Ridge
Continuation Area crosses a block boundary.
/usr/src/linux-*/fs/isofs/rock.c :

        int blocksize = 1 << rs->inode->i_blkbits;
        ...
        if ((unsigned)rs->cont_offset > blocksize - min_de_size ||
            (unsigned)rs->cont_size > blocksize ||
            (unsigned)(rs->cont_offset + rs->cont_size) > blocksize) {
                printk(KERN_NOTICE "rock: corrupted directory entry. "
                        "extent=%d, offset=%d, size=%d\n",
                        rs->cont_extent, rs->cont_offset, rs->cont_size);
                ret = -EIO;
                goto out;
        }

This throws for example

  Feb 16 10:57:56 ts5 kernel: rock: corrupted directory entry. extent=85, 
offset=1990, size=95

because (unsigned)(rs->cont_offset + rs->cont_size) > blocksize
where blocksize is 2048.

I cannot find this restriction in the SUSP specs about the
Continuation Area.
(http://www.ymi.com/ymi/sites/default/files/pdf/Systems%20Use%20P1281.pdf)
The CE entry format allows 32 bit numbers in rs->cont_offset
and rs->cont_size. If there was a restriction to the size
of a single block, then 16 bit would have been sufficient.

libisofs allocates a single extent for all Continuation Areas
in a directory. The directory /certs contains lots of links
with long names. These names fill more than one block.

-------------------------------------------------------------------

If this preliminary diagnosis is right, then the recorded data
are not damaged and can be retrieved by xorriso commands
  -osirrox on -extract /certs $HOME/copy_of_certs

Nevertheless, it is the goal of libisofs (and xorriso) to produce
Linux-mountable ISOs. So i will have to change libisofs to fulfill
the (probably incorrect) expectations of Linux.


Have a nice day :)

Thomas