Re: [grub-fs-tester.in] zisofs test looks unsuitable

[Glenn Washburn]

On Wed, 25 Aug 2021 12:29:48 +0200
"Thomas Schmitt" <scdbackup@gmx.net> wrote:

> Hi,
> 
> the xorriso run for testing zisofs in
> 
>   tests/util/grub-fs-tester.in
> 
> looks not like it would cause any zisofs compression in the ISO.
> 
> Line 1024:
> 
>       xorriso -compliance rec_mtime -set_filter_r --zisofs -- -zisofs
> default -as mkisofs ... some options ... --
>               -set_filter_r --zisofs -- -zisofs default -add
> /="$MASTER" ;;
> 
> should probably become
> 
>       xorriso -compliance rec_mtime \
>               -as mkisofs ... same options as above ... -- \
>               -add /="$MASTER" -- \
>               -zisofs default \
>               -set_filter_r --zisofs / --
>               ;;
> 
> In the current run, both times when "-set_filter_r --zisofs" is
> executed in xorriso's native command mode, the emerging root
> directory is still empty. So -set_filter_r cannot yet affect the
> files of "$MASTER" which get added only later.
> 
> Command -zisofs sets parameters for -set_filter_r. So it must be
> executed before any successful -set_filter_r. Only the lack of any
> installed compression filters keeps the existing run from failing with
>   libisofs: FAILURE : Cannot set global zisofs parameters while
> filters exist
> 
> Further:
> Command -set_filter_r expects one or more paths in the ISO as
> parameters. The empty path list defaults to "/" indeed, but that's
> not a documented feature.
> Command -add has a variable length parameter list and should thus be
> terminated by '--'. In my proposal it has to be terminated because
> more commands follow.
> 
> 
> Experiment:
> 
> Currently the run is essentially like
> 
>   xorriso -compliance rec_mtime \
>           -as mkisofs -o test.iso --graft-points -- \
>           -add /=test -- -set_filter_r --zisofs / --
> 
> My test directory contains
> 
>   -rw-r--r-- 1 thomas thomas 51200 Aug 25 11:51 zeros
>   -rw-r--r-- 1 thomas thomas     6 Aug 25 09:37 ÄÖÜß
> 
> No zisofs compression gets applied by above run to the files, as can
> be seen by a subsequent run of
> 
>   xorriso -indev test.iso -find / -exec show_stream --
> 
> which reports
> 
>   '/zeros' < image:'/zeros'
>   '/ÄÖÜß' < image:'/ÄÖÜß'
> 
> In contrast, my proposed xorriso run causes compression of file
> "zeros", which then causes the xorriso run with -indev to install a
> decompression filter to that file:
> 
>   '/zeros' < --zisofs-decode:pz:32k < image:'/zeros'
>   '/ÄÖÜß' < image:'/ÄÖÜß'
> 
> The small "ÄÖÜß" staid uncompressed, because compression yielded no
> gain in terms of 2048 byte blocks.

If I'm not mistaken, there is currently no test which actually
exercises that code, ie no test runs "grub-fs-tester ziso9660". I think
it could be a good idea to have one though.

However, when attempting to run the test manually, I'm getting a
failure probably related to what you've found.

$ ./grub-fs-tester ziso9660
xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev
'stdio:/tmp/tmp.82yFdjU5NO/ziso9660_512_512_1_0.img' Media current:
stdio file, overwriteable Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 4621m free
xorriso : FAILURE : -volid: Text too long (1650 > 32)
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'

I haven't dug very far, but I'm unsure if GRUB currently is supposed to
support this.

Glenn