[Gptfdisk-general] GPT fdisk 1.0.8 (was Re: GPTPart::GetDescription broken in 1.0.7 on Big Endian systems)

[Rod S. <rod...@ro...>]

This is a heads-up that I've released version 1.0.8, which fixes this
bug. It also adds a new feature to gdisk and sgdisk that enables
correcting a corrupted partition name. To use this feature:

* In gdisk, enter the experts' menu and then type 'b'. This will
  prompt you for a partition number (unless the disk has just
  one partition), shows the original and transformed names, and
  asks for verification. After you've fixed all the broken partition
  names, type 'w' to write your changes and exit.
* In sgdisk, use the new -B/--byte-swap-name parameter, which takes a
  partition number as an option. If valid, changes will be immediately
  written to disk.

This new feature works on any CPU architecture, but it probably won't be
necessary on x86 or x86-64. The bug doesn't affect little-endian CPUs
like x86 or x86-64, so the bug fix has no effect on them.

GPT fdisk 1.0.8 also adds a new partition type code for the Barebox boot
loader.

On 6/8/21 1:16 PM, Rod Smith wrote:
> On 6/8/21 12:21 PM, Erik Larsson wrote:
>> Hi,
>>
>> On 08-06-2021 18:16, Rod Smith wrote:
>>> On 6/8/21 10:54 AM, Christian Ehrhardt wrote:
>>>>> There aren't a lot of changes from 1.0.7 to the current
>>>>> state, but given that this is kind of important for big-endian systems,
>>>>> I'll release this change as 1.0.8 soon -- but I'll give it a day or two
>>>>> in case something else crops up.
>>>> Agreed, that little wait sounds wise.
>>>> I've indirectly also pulled IBM into the boat since they are kind of
>>>> the "master of big-endian things".
>>>> Maybe (but no promise) they have opinions/hints on this as well.
>>> I've been doing some searching to find a way to identify UCS-2 with
>>> swapped bytes, so that the program could fix this automatically when
>>> reading corrupted partition tables. (GPT technically uses UCS-2, not
>>> UTF-16, although the GPT fdisk code has a lot of references to UTF-16
>>> because at one time I relied on an external UTF-16 library.) So far no
>>> luck.
>>
>>
>> This problem is impossible to solve perfectly, however I would think
>> that partition labels with characters outside the ASCII range are very
>> rare in practice so for a start one could check if the first byte is 0
>> in every UCS-2 byte-pair.
>> If true, then it's almost certain that the label is in big endian (but I
>> would still ask the user to confirm that the big-endian interpretation
>> makes more sense).
> 
> Rather than implement something that stands a chance of getting things
> badly wrong, I'm leaning toward either doing nothing so that users can
> manually change partition labels, if desired; or implement an option to
> let users explicitly select partitions to byte-swap their labels. Either
> approach enables users to fix problems as they're detected, with the
> second option providing some help to users in recovering the original
> intended partition labels. Because most disk tools don't use partition
> labels for anything important, I don't think it's critical that these
> problems be corrected automatically. OTOH, automatically "fixing"
> something that's not broken, because of an algorithm that's prone to
> false alarms, could be really annoying.
> 
>> There are of course also some ranges that are reserved in Unicode that
>> can be used to detect that something might not be right with the
>> endianness and if we're limiting the allowed Unicode range to UCS-2 we
>> can exclude UTF-16 surrogate pair ranges (disallowing for instance the
>> poop emoji as a partition label).
>>
>> One could also check locality (text doesn't usually use characters from
>> all over the place in but stays within a few defined script ranges) and
>> there may also be statistical models based on the frequency that Unicode
>> characters occur in text,  but that's probably taking it too far. :)
>>
>> Best regards,
>>
>> - Erik
> 
> 


-- 
Rod Smith
rod...@ro...
http://www.rodsbooks.com