Re: GPT name overflow

[Andrew Clausen]

On Mon, Jan 28, 2002 at 03:58:05PM -0700, Andreas Dilger wrote:
> Hello,
> I was just testing GPT partitioning with parted-1.6.0-pre2 and I noticed
> a couple of minor issues:
> 
> 1) Entering a long name (over the 36 unicode character limit, I think)
>    made it abort with "Error during translation: Invalid or incomplete
>    multibyte or wide character".  I tried it with an 80-char input of
>    "aaa...aaa" and it worked OK (result truncated to 36 chars), but the
>    string "this is a long name which hopes to be too long" causes it
>    to abort on repeated tests.

I can't reproduce this.

At what point does it die?  Does enabling/disabling i18n make a
difference?

> 2) (this may be a parted usability bug and not GPT specific) if I try to
>    new partition and I specify a starting location which is the same as
>    the end of the previous partition it complains that the partitions
>    are overlapping instead of adding a small fudge factor.  If I manually
>    add .001 to the starting location it works, and often "print" will
>    report the starting location as being the same as the end of the
>    previous partition, e.g.
> 
>    (parted) p 
>    Disk geometry for /tmp/gpt: 0.000-10240.000 megabytes
>    Disk label type: gpt
>    Minor    Start       End     Filesystem  Name                  Flags
>    1          0.017    100.000              test_label            
>    (parted) mkpart p 100 200
>    Error: The new partition overlaps with another partition.
>    (parted) mkpart p 100.001 200
>    (parted) p
>    Disk geometry for /tmp/gpt: 0.000-10240.000 megabytes
>    Disk label type: gpt
>    Minor    Start       End     Filesystem  Name                  Flags
>    1          0.017    100.000              test_label            
>    2        100.000    200.000

Yep, this should be "fixed".  Just, I've been procrastinating about
a nice clean/general solution.  There are a few special cases.

How does this sound:
* if (geom->start + geom->end)/2 is freespace then set geom to
ped_geometry_intersect (geom,
        &ped_disk_get_part_by_sector (disk, (geom->start + geom->end)/2)
                ->geom)
where geom is what the user specified.  Actually, a bit more
bureaucracy, to only move within a certain fudge-factor.
(That bit is already implemented)

* for resizing, it's a bit trickier.  The obvious solution is
to remove the partition, and add it back again, but this might
lose some flags, etc.  (is it THE boot partition, etc?)
So, it's best to avoid remove/add.  OTOH, we could do the
math on a duplicate of the partition table, but duplicating
the partition table is a fair bit of work.  Feels wrong.

I think a better solution is to add the freespace on either
side of the partition, and intersect on that.

> 3) Since GPT only supports primary partitions (and probably other label
>    types also), it would be nice to avoid having it ask what partition
>    type when working in interactive mode.  This is probably true of any
>    input which only has a single choice.  I can see that you might need
>    to keep it for single command-line inputs to make the parsing sane.

Yep, I thought I already implemented this...

one gotcha:

There might be two "options" that are the english and native
versions of the same thing.  So, either we have to implement this
at a higher level (PITA), or the UI code should know the difference
between native and english words.  I think we need the later anyway.

> 4) GPT doesn't seem to keep the "type" of a partition, or parted doesn't
>    print it out with 'p' correctly.  It is my understanding that GPT has
>    GUIDs instead of single-byte partition types,

Right.

> so parted should probably
>    print these as flags, but it does not (unlike msdos partitions):
> 
>    (parted) set 1 boot on
>    (parted) set 2 raid on
>    (parted) set 3 lvm on
>    (parted) p
>    Disk geometry for /tmp/gpt: 0.000-10240.000 megabytes
>    Disk label type: gpt
>    Minor    Start       End     Filesystem  Name                  Flags
>    1          0.017    100.000              test_label            
>    2        100.000    200.000                                    
>    3        200.000    300.000                                    

You found a bug.  Thanks :)

Andrew