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

[Thomas Schmitt]

Hi,

as promised, the candidate for making large SUSP data
digestible for Linux fs/isofs.

To replace libisofs/rockridge.[ch] :

  http://scdbackup.webframe.org/rockridge.h.gz
  http://scdbackup.webframe.org/rockridge.c.gz

The files may be copied into xorriso-1.3.9 or xorriso-1.3.8.

After removing the development macros i committed the
files to libisofs bzr on Launchpad:
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1184

Heavy testing would be appreciated.


---------------------------------------------------------------
A test setup for long AAIP:

  echo fattr_xxl >/u/test/fattr_xxl

  for i in $(seq -w 1 30)
  do
    setfattr -n "user.name""$i" \
             -v $(for j in $(seq 1 55) ; do echo -n "$i" ; done) \
             /u/test/fattr_xxl
  done

which on ext3 and linux-2.6 fails to do the last of 30
setfattr runs with:
  setfattr: /u/test/fattr_xxl: No space left on device
(There is lots of space and inodes available. It seems
 inappropriate to issue errno ENOSPC in this situation.)

  getfattr -d /u/test/fattr_xxl

yields

  # file: u/test/fattr_xxl2
  
user.name01="01010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101"
  ...
  
user.name29="29292929292929292929292929292929292929292929292929292929292929292929292929292929292929292929292929292929292929"

Well, at least it suffices for more than 2048 bytes
of AAIP entries.

Packed up by

  xorriso-1.3.8 -for_backup -outdev /dvdbuffer/test.iso \
                -map /u/test/fattr_xxl /fattr_xxl

and mounted as Linux fs/isofs to /mnt/iso, the file
/mnt/iso/fattr_xxl is not shown by ls -l.
In /var/log/messages appears the complaint:

  Feb 25 09:53:42 ts5 kernel: rock: corrupted directory entry. extent=52, 
offset=286, size=3609

Packed up by the newest xorriso-1.3.9 snapshot, the file
shows up with ls -l. No complaints appear in the system log.
Program isoinfo does not complain either.

The attributes do not show up with /mnt/iso/fattr_xxl,
because Linux fs/isofs neither knows AAIP nor expects
xattr stored in any other way.
At least it follows mostly the SUSP rule:
"Reader does it right."
I.e. not to demand to understand any SUSP field content.

The attributes can be inquired (and restored) by xorriso

  xorriso -indev /dvdbuffer/test.iso \
          -getfattr /fattr_xxl --

yields

  ...
  # file: fattr_xxl
  
user.name01="01010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101"
  ...
  
user.name29="29292929292929292929292929292929292929292929292929292929292929292929292929292929292929292929292929292929292929"

xorriso command 
  -find /fattr_xxl -exec get_any_xattr --
will also show
  isofs.di="\002\010\005\003\031\000u"
  isofs.cx="\000\000\000\001"

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

The SUSP list of /fattr_xxl now contains two CE entries.
The first is at the end of the directory record. It
points to byte 0 of block 53 and announces 1813 bytes.
The last 28 of these bytes are the second CE entry,
pointing to byte 0 of block 54 and announcing 1824 bytes.
So no CE points to a range which would cross a block
boundary. 

To my luck, Linux fs/isofs is willing to accept or ignore
the second CE. (Telling from the source code i'd say that
it will really hop to block 54 and go on scanning.)

The SUSP-granularity of 255 bytes per entry causes quite
some waste here. One could think about adaptive size of
AAIP entries. But that would make everything even more
complicated.
It seems that large xattr are not overly common (as long
as we do not enter the Solaris world of fsattr(5)).
So the waste is hopefully bearable.


Have a nice day :)

Thomas