Re: GPT name overflow

[Andrew Clausen]

On Wed, Jan 30, 2002 at 02:39:30PM -0700, Andreas Dilger wrote:
> Hmm, maybe a glibc wchar problem?  I'm using glibc 2.1.3-33.  The message
> appears to be from parted/strlist.c, and I hit it even with a totally
> different string "trying a new string which is longer", but not the longer
> "asdf asdf asdf asdf asdf asdf asdf asdf asfd".  Strange.

What does it actually do?  Seg fault?

> Hmm, I just tried to run "LANG=de parted /tmp/gpt" (also LANG=ca, LANG=pt)
> and it replied:
> 
> Error during translation: Ungültiges oder unvollständiges Multi-Byte oder
> Wide-Zeichen

This is a charset issue... I think you need to set LC_CTYPE=de_DE
(or LC_ALL).  I've had heaps of problems with i18n :(

> which, as you can guess is the same as the "Error during translation:
> Invalid or incomplete multibyte or wide character".  The two systems
> I've tested this on are both based on an older TL 6.0 install, which
> I've been updating as newer RPMs are needed.  Maybe it is a glibc bug.
> The alternative is that there is a memory overrun somewhere which is
> corrupting the wchar handling (no segfaults though), I don't know.

I've been able to reproduce these problems with i18n in small
tests programs outside of parted.

> What libraries are involved with this translation?  Maybe I need to
> update something?

Just glibc, FWICT.  The intl/ dir seems to be unused in the normal
case.  (WTF can't we link dynamically, and not have to distribute it!)
<whinge>The parted tarball is now over a meg, with 90% of it crap
that doesn't get used</whinge>

> > This is the "high-level" approach that I didn't like... 
> > (low-level: one option [for anything]... don't bother asking]
> 
> Yes, that would be nicer, I agree, if it is reasonably easy to do.

Very easy :)  One thing that bothers me:

"Which partition to delete? 3"
(there's only 1!)

I think I'll just make "the only option" default, so you can
just bash enter.

> It
> turns out that my patch core dumped anyways.  One new bug that I see is
> if you compile without fs support then do_mkpart() breaks because you
> will never be able to find a matching fs type.  It should probably just
> continue on (none of the lower-level code appears to require the fs_type.

Thanks, I'll take a look...

> > > Yes, having the low-level code also handle translations would be nice.
> > > Maybe by keeping the translated word in the same option for display,
> > > and the call to command_line_get_word() only returns the english word?
> > > That would also simplify the resulting checks.
> > 
> > The checks are fairly easy already, via the str_list mess, hehe.
> > But only displaying the translated words is better.  It's a bit
> > silly displaying:
> > 
> > Erro: blah blah blah
> > Yes/Sim/Ignore/Ignorar/Cancel/Cancelar
> 
> Well, for some classes of messages it may help to allow the user to see
> both the english and translation, as I've heard it reported that sometimes
> the english term is more widely used than a literally-translated word.

In that case, the translator (person) should use the more widely used
term.  BTW: the user can see the options (including english) available
with readline by hitting tab twice.

> You could always re-structure the str_list to work like (vaguely):
> 
>       add_unique_str("primary", _("primary), list);
> 
> The (optionally) translated string is the only one which is displayed.
> It's too bad that there isn't an inverse to the _() operation.  You would
> get the return value from the selection the first string (== key), not the
> translated (displayed) value.

Interesting...

Well, str_list is a rather silly hack (that just happened to
be useful with the same interface in a few different places).
I should probably separate it into a generic list, and a
i18n_string, etc.  Just, I suspect it would be rather clumsy
that way...

I'll think about a more elegant solution...

> > Nope, more subtle: it's not updating the uuid, so it's not getting
> > written to disk.  Parted always reads the partition table each
> > time you type "print".
> 
> Well, I was looking at gpt_set_system() and not gpt_set_flags(), so you
> are correct that it doesn't set the UUID at all.  Semi-tested patch below.
> It removes the ->lvm, ->raid, ->boot booleans from the GPT-private data
> and just compares the UUID fields directly.  This is better because you
> avoid duplication of state, and it will also work for data read from disk.
> It also adds support to the "swap" type which you didn't handle from
> "set X swap on" before.

Unfortunately, it has the wrong semantics (IMHO). (It isn't really
duplication of state...)

If the user makes a reiser system (as opposed to an ext2 one
that was there before, for example), then ped_partition_set_system()
will be called, with the new fs type.

If this partition is a boot partition, and you just blindly assign
"reiser", then you just lost your boot flag.

Sure, you could check if it was boot beforehand, but I think it's
cleaner with the flags separate.

> On a related note - how can you specify a particular partition type when
> running mkpart for DOS partitions?

You can only specify a file system type, which maps onto a subset
of partition types.

>  It seems parted (and libparted) make
> this intentionally difficult to do.  What if you wanted to set a particular
> GUID (unknown to parted) as the partition type for a GPT partition?

Partition types are The Wrong Thing TM IMHO.  They are always a function
of something more intuitive/practical (like a boot flag, or lba flag,
or the file system type), so it's better to provide an interface for
what the types all mean, rather than display them directly.

This also means parted present a consistent interface for setting
the boot partition, etc.

Do you know how to choose the right FAT partition ID?  There are about
30 to choose from...

Anyway, I have no ethical objections to adding an support for
playing with IDs directly (not that I see this as useful...
the solution to the unknown GUID type problem is to update parted)
... just again, I'd rather use an evms-param-like interface.

Andrew