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

[Joerg Meyer]

Hi Thomas 

I might be to tired and/or too stupid again,
but for whatever reason I do not seem to able to store extended attributes with 
xorriso-1.3.[8,9] -
see attached script and output.
Increasing the number of attributes to 100 does not make any difference.
It fails equally also on an ext4 filesystem (within an image file of the btrfs).
I hope it's nothing too obvious that I miss here?!

Best wishes,
Jörg.


On 26 Feb 2015, at 18:10, Thomas Schmitt <address@hidden> wrote:

> 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
>

fattr-xxl.sh
Description: Binary data

fattr.out.gz
Description: GNU Zip compressed data