[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GPT name overflow
From: |
Andreas Dilger |
Subject: |
Re: GPT name overflow |
Date: |
Wed, 30 Jan 2002 11:52:53 -0700 |
User-agent: |
Mutt/1.2.5.1i |
On Jan 31, 2002 01:35 +1100, Andrew Clausen wrote:
> On Mon, Jan 28, 2002 at 03:58:05PM -0700, Andreas Dilger wrote:
> > 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?
Hmm, I was able (on subsequent tests) to get it to fail with "this is a long
name which h" but not "this is a long name which ". This is with 1.5.6. I
also tried with 1.6.0p2 with the same results. Note that the name does not
even overflow the 36 (I think) character limit.
> > 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)
What about:
if (geom->start == (geom prev)->end)
then geom->start = (geom prev)->end + 1;
I don't know how hard it is to do this, but you need to have access to
the (geom prev)->end _somewhere_ in order to check if it is overlapping.
> > 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.
I did this last night for the partition type (which is the one which I
see most when doing GPT partitions == always primary). Untested patch below.
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.
> > 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 :)
I checked the GPT code, and it does appear to set the "flags" correctly.
Sadly, even though GPT uses 16 bytes for the UUID storage, you can only
set a single "flag" at one time (i.e. you can't have a boot RAID partition).
It must just not do the later comparison to display the flags.
Cheers, Andreas
======================== parted-1.6.0-pre2-type.diff =========================
--- parted/ui.c.orig Sat Jan 12 14:17:55 2002
+++ parted/ui.c Wed Jan 30 11:44:10 2002
@@ -684,22 +684,27 @@
PedPartitionType* type)
{
StrList* opts = NULL;
- char* type_name;
+ char* type_name = NULL;
+ int num = 0;
if (_can_create_primary (disk)) {
- opts = str_list_append_unique (opts, "primary");
+ opts = str_list_append_unique (opts, (type_name = "primary"));
opts = str_list_append_unique (opts, _("primary"));
+ num++;
}
if (_can_create_extended (disk)) {
- opts = str_list_append_unique (opts, "extended");
+ opts = str_list_append_unique (opts, (type_name = "extended"));
opts = str_list_append_unique (opts, _("extended"));
+ num++;
}
if (_can_create_logical (disk)) {
- opts = str_list_append_unique (opts, "logical");
+ opts = str_list_append_unique (opts, (type_name = "logical"));
opts = str_list_append_unique (opts, _("logical"));
+ num++;
}
- type_name = command_line_get_word (prompt, NULL, opts, 1);
+ if (num > 1)
+ type_name = command_line_get_word (prompt, NULL, opts, 1);
str_list_destroy (opts);
if (!type_name) {
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
- GPT name overflow, Andreas Dilger, 2002/01/28
- Re: GPT name overflow, Andrew Clausen, 2002/01/30
- Re: GPT name overflow,
Andreas Dilger <=
- Re: GPT name overflow, Andrew Clausen, 2002/01/30
- Re: GPT name overflow, Andreas Dilger, 2002/01/30
- Re: GPT name overflow, Andrew Clausen, 2002/01/31
- Re: GPT name overflow, Andreas Dilger, 2002/01/31
- Re: GPT name overflow, Andrew Clausen, 2002/01/31