From: "Thomas Schmitt" <scdbackup@gmx.net>
To: grub-devel@gnu.org
Subject: Re: [PATCH] [PATCH] tests: Keep grub-fs-tester ziso9660 from failing for wrong reasons
Date: Wed, 08 Sep 2021 23:03:39 +0200 [thread overview]
Message-ID: <7135362548759968545@scdbackup.webframe.org> (raw)
In-Reply-To: <20210908190445.fv6zartuu4js5eqc@tomti.i.net-space.pl>
Hi,
i am working on the requested changes.
In my patch message i wrote:
> > A bug
> > in xorriso causes a distracting warning about FSLABEL being too long for
> > Joliet. Shortcommings of Joliet cause warnings about symbolic links.
Daniel Kiper wrote:
> s/links./links too./?
Rather not. Both warnings have very different reasons.
The xorriso bug was that the warning came if more than 16 bytes of volume
id are submitted. The correct test is to count the UCS-2 characters after
conversion from the local character set (meanwhile surely UTF-8).
The FSLABEL which is prepared by grub-fs-tester for ISO 9660 tests has
only 15 characters but 32 UTF-8 bytes.
The shortcomming of Joliet is in its specs. It was invented by Microsoft
Inc. for presenting Microsoft filesystem names. At least back in 1995
no symbolic links were desired for their version of ISO 9660. Other than
the xorriso bug i cannot fix this.
Both warnings could deceive the reader of the test report, especially
since the test is expected to fail. Thus my patch disables Joliet to
silence both for all xorriso versions.
> I have an itching to ask you to split this thing into two patches.
I decided against this because the test would indicate false success
after the early failure because of the FSLABEL length is fixed.
If i fix the xorriso command sequence problem first, then this first
patch does not have any effect at run time.
So i rather consider the ziso9660 test as untested sketch which i replace
by a working test with proper failure as long as no zisofs decompression
is implemented.
> You described everything in the commit message what you are doing here
> except of "-set_filter_r --zisofs -- -zisofs default" games. Could you
> explain that too?
Will try without copying a whole paragraph from man xorriso.
Have a nice day :)
Thomas
prev parent reply other threads:[~2021-09-08 21:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-08 11:10 [PATCH] [PATCH] tests: Keep grub-fs-tester ziso9660 from failing for wrong reasons Thomas Schmitt
2021-09-08 11:18 ` Thomas Schmitt
2021-09-08 19:04 ` Daniel Kiper
2021-09-08 21:03 ` Thomas Schmitt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7135362548759968545@scdbackup.webframe.org \
--to=scdbackup@gmx.net \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.