All of lore.kernel.org
 help / color / mirror / Atom feed
From: Glenn Washburn <development@efficientek.com>
To: "Thomas Schmitt" <scdbackup@gmx.net>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH v2 1/8] tests: Make sure LANG is set properly for iso9660_test
Date: Thu, 26 Aug 2021 15:16:40 -0500	[thread overview]
Message-ID: <20210826151640.45f9fe81@crass-HP-ZBook-15-G2> (raw)
In-Reply-To: <11704360906509513569@scdbackup.webframe.org>

On Thu, 26 Aug 2021 19:49:37 +0200
"Thomas Schmitt" <scdbackup@gmx.net> wrote:

> Hi,
> 
> now i know that i should have asked for the test-suite.log file.
> 
> The problem turned out to be in Joliet, not in ISO 9660.
> Because Joliet gets its file names and other texts encoded as UCS-2
> 16-bit characters it is indeed inavoidable to define the meaning of
> the bytes in a Unix file name.
> The UTF-8 sequence \303\251 has no meaning as ANSI_X3.4-1968
> characters (which are what we learned to love as 7-bit ASCII). So
> iconv fails.
> 
> My remedy proposal
> 
>   xorriso ... -as mkisofs -input-charset UTF-8 -output-charset UTF-8
> ...

Do there need to be any UTF-8 locales installed (or any locales for
that matter) for this to work? My guess is no.

> turned out to be a valid alternative to
> 
>   LANG=en_US.UTF-8
> 
> Using above charset options unconditionally would make obsolete the
> warning in Glenn Washburn's patch at least for the xorriso runs:
> 
>   +elif [ -n "${LANG##*UTF*}" ]; then
>   +   echo "WARNING: LANG=$LANG appears to not be unicode,
> international file test may fail."
> 
> It would still be beneficial to default LANG="" to LANG=en_US.UTF-8
> because 7-bit ASCII is really an odd character interpretation for Unix
> filenames. (HP-UX from 1986 maybe ...)

Correct me if I'm wrong, but this logic about defaulting LANG is more
general than the iso9660_test. Would you agree that this should be
applied to the tests a a whole?

If yes, then I should probably remove this patch altogether and put
this code elsewhere.

--------------------------------------------------------------------------
> 
> Noob question:
> How can i force "make check" to do something at its second run ?

I might be answering this question below.

--------------------------------------------------------------------------
> Long story:
> 
> On a Debian 10 with a freshly made GRUB git clone i see indeed a
> failure of iso9660_test with mutilated volume id and a mutilated
> exotic filename after
> 
>   make SUBDIRS= LANG= TESTS=iso9660_test check
> 
> On the same machine with the same xorriso, the same file name from the
> log and the volume id taken from the script, i get with
> 
>   LANG= xorriso -as mkisofs -o test.iso -V "...exotic.characters..."
> test_tree
> 
> a somewhat confused xterm (or libreadline) but
> 
>   xorriso -indev test.iso -find / --
> 
> reports the exotic volume id and the exotic filename.
> 
> The "make ... check" run says on the second try
>   make[3]: 'iso9660_test' is up to date.
> but i can reproduce the problem by
> 
>   LANG= ./grub-fs-tester joliet

Yes the iso9660_test is up to date in the sense that it does not need
to be generated from iso9660_test.in. However, "make check" should
still be running the test. IOW, the tests are always rerun, there is no
make rule that does not run tests based on them having been perviously
run (that I know of).

> The trigger for the file name mutilation seems to be the mkisofs
> emulation option for creating a Joliet tree
>   -J
> With default settings of mount(8) or xorriso's file name display the
> problem becomes visible only if no Rock Ridge info was added to the
> ISO 9660 tree. This is caused by xorriso command
>   --rockridge off
> 
> Nevertheless file(1) and xorriso still see the exotic volume id.
> Binary inspection shows that the ISO 9660 volume id (at offset 32768
> + 40) is originally exotic, but the Joliet volume id (at offset 34816
> + 40) was mutilated.
> 
> So obviously the problem sits in the Joliet name conversion to UCS-2.
> It is inavoidable if the file names do not match the input character
> set (defaulted from locale) because the Unix file names cannot be
> just copied to Joliet directory records.
>
> Now that i can reproduce the problem i can also confirm that my remedy
> proposal would work as expected. It preservies the exotic names in the
> Joliet tree and the exotic volume id in the Joliet supplementary
> volume descriptor.

As i understand it, your proposed change is entirely with in
grub-fs-tester. Would you submit a patch with the changes you've
outlined that would fix this issue for when LANG is empty? Based on the
work you've done, I think it makes most sense for you to author the
patch. And I'll test/review it.

Glenn


  reply	other threads:[~2021-08-26 20:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-25  7:03 [PATCH v2 0/8] Various fixes/improvements for tests Glenn Washburn
2021-08-25  7:03 ` [PATCH v2 1/8] tests: Make sure LANG is set properly for iso9660_test Glenn Washburn
2021-08-25  9:34   ` Thomas Schmitt
2021-08-25 19:49     ` Glenn Washburn
2021-08-26  6:53       ` Thomas Schmitt
2021-08-26 17:06         ` Glenn Washburn
2021-08-26 17:49         ` Thomas Schmitt
2021-08-26 20:16           ` Glenn Washburn [this message]
2021-08-26 21:28             ` Thomas Schmitt
2021-08-26 22:30               ` Glenn Washburn
2021-08-27 19:13                 ` Thomas Schmitt
2021-08-27 20:03                   ` Glenn Washburn
2021-08-27 21:23                     ` Thomas Schmitt
2021-08-25  7:03 ` [PATCH v2 2/8] tests: Fix partmap_test for arm*-efi, disk numbering has changed Glenn Washburn
2021-10-06 13:45   ` Daniel Kiper
2021-08-25  7:03 ` [PATCH v2 3/8] tests: When checking squashfs fstime, use superblock last modified time Glenn Washburn
2021-10-06 13:46   ` Daniel Kiper
2021-08-25  7:03 ` [PATCH v2 4/8] tests: Fail immediately when grub-shell fails and do not occlude the error code Glenn Washburn
2021-10-06 13:57   ` Daniel Kiper
2021-10-06 20:05     ` Glenn Washburn
2021-10-07 12:37       ` Daniel Kiper
2021-10-07 15:35         ` Glenn Washburn
2021-08-25  7:03 ` [PATCH v2 5/8] tests: Make setup errors in grub-fs-tester hard errors Glenn Washburn
2021-10-06 15:26   ` Daniel Kiper
2021-08-25  7:04 ` [PATCH v2 6/8] tests: A failure of mktemp should cause the test script to exit with code 99 Glenn Washburn
2021-10-06 15:28   ` Daniel Kiper
2021-08-25  7:04 ` [PATCH v2 7/8] tests: Exit with skipped exit code when test not performed Glenn Washburn
2021-09-17 21:42   ` Glenn Washburn
2021-10-06 15:34     ` Daniel Kiper
2021-08-25  7:04 ` [PATCH v2 8/8] tests: Use @BUILD_SHEBANG@ autoconf var instead of literal shell Glenn Washburn
2021-10-06 15:37   ` Daniel Kiper

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=20210826151640.45f9fe81@crass-HP-ZBook-15-G2 \
    --to=development@efficientek.com \
    --cc=grub-devel@gnu.org \
    --cc=scdbackup@gmx.net \
    /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.