GNU bug report logs - #15591
gpt mishandles non ascii partition names

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Rod Smith <rodsmith <at> rodsbooks.com>
Subject: bug#15597: closed (Re: [PATCH] libparted: handle i18n gpt
 partition names correctly)
Date: Mon, 23 Dec 2013 03:46:03 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#15591: bug-parted Digest, Vol 131, Issue 9

which was filed against the parted package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 15597 <at> debbugs.gnu.org.

-- 
15591: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15591
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jim Meyering <jim <at> meyering.net>
To: Phillip Susi <psusi <at> ubuntu.com>
Cc: 15591-done <at> debbugs.gnu.org
Subject: Re: [PATCH] libparted: handle i18n gpt partition names correctly
Date: Sun, 22 Dec 2013 19:45:06 -0800

Perfect.  Thanks!  Marking this "done" in the bug-tracker.

[Message part 3 (message/rfc822, inline)]

From: Rod Smith <rodsmith <at> rodsbooks.com>
To: bug-parted <at> gnu.org
Subject: Re: bug-parted Digest, Vol 131, Issue 9
Date: Sat, 12 Oct 2013 12:33:12 -0400

On 10/12/2013 12:01 PM, Phillip Susi <psusi <at> ubuntu.com> wrote:

> The gpt partition table has 16 bit characters for the name, which I
> assume are supposed to be UTF-16, but the bloody uefi standard is moot
> on the subject.

The standard says they're "strings," and the default for strings in UEFI 
is UTF-16LE/UCS-2.

> Currently parted simply decimates the characters,
> throwing out the upper 8 bits.  This corrupts characters that aren't
> simple ascii, and at some later point, strlist.c calls mbstrtowcs(),
> which chokes on the corrupt name causing parted to bail out with
> "Error during translation".
>
> I think that gpt.c needs to translate the UTF-16 to the native
> multibyte encoding, but I have no idea how to do that.  The C standard
> conversion functions all seem to use the current locale and don't have
> a way to override it if you know this string is in UTF-16 ( and maybe
> the current locale is UTF-8 ).

I agree with you. I haven't studied the parted code on this score, so I 
don't have any specific suggestions for how to do it in parted. I can 
offer my experiences with doing it in GPT fdisk 
(http://www.rodsbooks.com/gdisk/), though: I used libicu 
(http://site.icu-project.org/) to do the translation. This seems to work 
pretty well -- at least, it produces results that are inter-operable 
with what Apple's tools do. You can check the gdisk source code, and 
particularly the gptpart.cc file, to see how gdisk does it. Search for 
"UnicodeString" to find what it does. It's been a while since I added 
libicu support, and I haven't made many changes to it since then, so I 
don't recall every detail of what I did. I seem to recall that it wasn't 
really very hard, but I did need to change quite a few output functions 
to use the libicu calls.

FWIW, when I added libicu support to gdisk, I kept the option to compile 
without libicu, in which case gdisk mangles non-ASCII characters in much 
the way parted does. Thus, you'll see both sets of code in gdisk. As a 
practical matter, libicu is a rather large library, and some developers 
of small emergency disks don't want to include it, so keeping the option 
to not use libicu is worthwhile.

Note that some values are invalid even with libicu, so there's a 
possibility that you'll run into error conditions, whether using libicu 
or not. Obviously, sane error handling is better than having the code 
bail out.

-- 
Rod Smith
rodsmith <at> rodsbooks.com
http://www.rodsbooks.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.