Comment on attachment 232461 [details]
Commands for gdisk to create a test gpt partition table

I could write a patch if you wish.

Hi Sinlu, thanks for pointing out this area for enhancement.  Your
offer to write a patch is gracious, and would certainly be
appreciated.

Following is a tip on using disk images via loop devices with GParted,
and an initial discussion of possible GUI options for this
enhancement.

TIP:  HOW TO USE GPARTED, LOOP DEVICE, AND DISK IMAGE
-----------------------------------------------------
Regarding the test steps you listed above, you can setup a loop device
using the disk image so that you can work with it in GParted.

To setup a loop device with a disk image:
$ sudo losetup /dev/loop0 tmpdisk.img

To remove the loop device:
$ sudo losetup -d /dev/loop0

To work with the loop device in GParted:
$ sudo gparted /dev/loop0


GUI POSSIBILITY THOUGHTS
------------------------
Currently volume labels (or file system labels) are referred to in
GParted under the "Partition --> Label" menu.  With this suggested
enhancement we will also have real partition labels in the GPT
partition table entry.  This will likely cause confusion for users,
and should be addressed in the GParted GUI.

Since GParted incorrectly refers to volume labels as partition labels,
I believe we will need to make some changes to the GUI to make the
label distinction clear.

I have two thoughts on how to approach this problem of label
confusion:


A)  ENHANCE PARTITION INFORMATION WINDOW TO BE PARTITION PROPERTIES

Currently the partition information window is used for display only.
However, this window could be renamed to Properties and enhanced to
become a true properties window with some editable properties.

Much of the current information in the window would remain read-only.
Other properties would become editable, and the window would require a
CANCEL button and logic added to the OK button to process what to do
if an editable property is changed.

I think the following properties would be editable in this new
properties window:

    EDITABLE PARTITION PROPERTIES:
      GPT Partition Name (label)
      File system         (i.e., reformat to a different file system)

    EDITABLE FILE SYSTEM PROPERTIES:
      Volume Label
      UUID

The above suggested properties window would enable us to remove the
following menu entries under the top level "Partition" menu:
      Format to
      Label
      New UUID

An added advantage to this method is that a user could specify a
volume label when reformatting a partition to a different file system.
Currently this must be done in two separate steps, assuming that the
file system supports changing the volume label.


B)  CREATE A NEW FILE SYSTEM TOP LEVEL MENU

Another approach to lessen the confusion between volume labels and
partition labels involves adding a new "File System" top level menu.
I think the "File System" menu would belong between "Partition" and
"Help".

The two menu items to move from the "Partition" menu to the new "File
System" menu would be:
     Label   (i.e., volume label)
     UUID

Under the "Partition" menu, we would add the new GPT partition name/label.


These are two ways I think we can change the GUI to lessen the
confusion between volume labels and partition labels.  I am open to
hearing other options too, and would like to hear your comments on the
above two GUI change approaches.

Created attachment 232698 [details] [review]
read only partition name support (v1)

Hi Curtis, thank you for sharing your thoughts.

My findings for the options:

A)  enhance partition information window to be partition properties
-------------------------------------------------------------------
This sounds good, even though when doing implementation it has to
be taken care of multiple edits.
For example clicking on the "new uuid" checkbox (I think a checkbox is
the best solution here) does not have to be considered when a new
filesystem is selected. Formatting to even the same filesystem type creates
already a new uuid.
This might also cause confusion to user as he enabled the uuid checkbox
while the "new uuid"-command does not appear.

B)  create a new file system top level menu
-------------------------------------------
Here the question arises about what to do with the right-click menu in the
partition table.
Currently it is equal to the partition top level menu.
It can't be split up, but submenus are possible.

About Implementation cost:

B) seems easier to implement as A) because of being abled to keep more gui code.
A) looks a bit invasive as many aspects are involved.

I'm unfamiliar with gtk GUI coding. Editing or copying of existing code should
work, but writing entirely new code is not so easy for me.

Partition information window
----------------------------

The partition information window doesn't have the separation between partition
and filesystem which has to be added on both cases.
So some reorder needs to be made. My suggestion:
headline: "filesystem"
filesystem
used/unused
status
label
uuid
 (blank line)
headline: "partition"
path
size
GPT name
optional: GPT unique UUID
flags
 (blank line)
sector information (3 lines)

OTHER THOUGHTS
--------------

Thank you for the tip about losetup. I only knew kpartx which created the
partitions in /dev/mapper and the disk as /dev/loop$n.

parted provides two very helpful functions for GPT labels:
ped_partition_get_name
ped_partition_set_name

I wrote a patch that uses the first function. No big changes to GUI
were made yet.

There are GPT managed UUIDs too, but these cannot be read so easily
as the partition name. Only ways seem:
-> udev (via ls -l /dev/disk/by-partuuid)
-> gdisk (still beta according to man page of 0.8.5)

I think being abled to edit the partition label while the filesystem is mounted
is a great feature but might cause system instability. This needs more testing.

Greetings,
Sinlu

Hi Sinlu, thank you too for sharing your thoughts.  :-)

You make some good points.

A)  ENHANCE PARTITION INFORMATION WINDOW TO BE PARTITION PROPERTIES

As you point out, it does not make sense to "set a new-UUID" when the partition has been selected to be "formatted with a new file system".  As such there will need to be some good logic here to "do the right thing".

B)  CREATE A NEW FILE SYSTEM TOP LEVEL MENU

Another good point you raise is that there is only one right click menu.  Though sub-menus are possible, I think it would be best if we keep the menu simpler, rather than making it more complex.


I think that option (A) is the best long term solution.  However, this could be done in a separate bug report.

SUGGESTED APPROACH
------------------
In order to provide you the opportunity to learn more about gtkmm GUI coding, perhaps we could approach this enhancement in the following manner:

1)  Add the read "GPT name" functionality as in your comment #3 patch.

    Question 1:  Is this new "GPT name" feature only available with
                 GUID Partition Tables?

2)  Re-organize the partition information window using your suggestions in
    comment #3.
    Note that in the GUI we chose to display "File system" as two separate
    words, as opposed to "Filesystem".
    Also we will need to handle the LVM2 PV information appropriately too.

3)  Add the write "GPT name" functionality, by adding a "GPT name" to the
    "Partition" menu.
    Note that this will be a short term plan until we tackle implementing
    option (A).
    Doing this will require going through the Dialog_Partition_New
    and Dialog_Base_Partition methods which helps with learing
    gtkmm GUI coding.

4)  Create a new bug report and implement option (A).

I can take care of the corresponding updates to the GParted Manual if that would help.


OTHER THOUGHTS
--------------
I agree that being able to edit the partition label while the file system
is mounted would be a great feature.  Something similar has been requested
in:

Bug #600496 - Allow changing ext2/3 label without unmounting partition

As you point out, we will need to test to ensure that online changes work
reliably.  We will want to do this in a way that enables us to do similar
online work, such as growing a btrfs or ext4 file system while mounted.

Hi Curtis,

I would welcome it if you write the documentation.

I created the bug #691681, as stated in step 4).
I think taking care of both window and Partition name in one step is easier to implement.
I already have an implementation of B) in my local git, but it uses "Filesystem" in UI, and it only supports GPT.
Enhancing it to publish it as a patch would require more work than improving the partition name window.

QUESTION 1:
OTHER PARTITION NAME SUPPORTING PARTTABLES
------------------------------------------

There are also other partition labels than just GPT supporting Partition names.
I got the information from libparted source:

mac
 32 chars max
 libparted/labels/mac.c:1353
gpt
 already handled: 36 chars max
rdb (rigid disk block is unsupported by gparted as it seems (at least in disklabel dialog) )
 32 chars max.
 libparted/labels/rdb.c:1015
dvh
 8 chars max, but "only logical partitions (boot files) have a name."
 understanding this message apparently needs knowledge about dvh which i lack.
 So i will comment out any support for dvh.
 references:
 libparted/labels/dvh.c:723
 libparted/labels/dvh.h:112
pc98
 16 chars max
 libparted/labels/rdb.c:1015

According to libparted implementation, exactly all disktypes that are supporting
partition name reading also support partition name writing.

As libparted does not ship with an interface to access the maximum length,
they need to be hardcoded as in my patch for #689318.

As not only GPT supports partition names, i think it would be best to rename the feature "gpt name" to "partition name".

Hi Sinlu,

Thanks for researching further into the partition tables that support partition names.  Your initial design decisions in this area sound good to me.

When these patches near completion, I will begin to update the documentation.

If you have any questions along the way, please feel free to ask.

Hi Sinlu and Mike,

Thank you Mike for assisting with this patch, and thank you Sinlu for
making the changed suggested by Mike.

The patch in comment #30 applies and compiles for me.  The warnings on
trailing whitespace in the file rename commit are to be expected since
these exist in the file being renamed.


This patch marks a significant change to GParted.  As such I think it
best to re-iterate why we think it is beneficial to make the change
from a read-only partition information dialog to a read/write
partition properties dialog.


REASONS TO CREATE EDITABLE PARTITION PROPERTIES DIALOG

1)  Request to add another label operation (GPT Partitions)

Currently GParted supports volume labels, which are changed via the
"Partition --> Label" menu.  Sinlu has pointed out that GUID
Partitions can also contain their own label.  Unfortunately the
current GParted names are not set up well to deal with a File System
Label (also volume label), and a Partition Label (in GPT).  Hence we
would need to at least change the menu entries.

Reference:  Bug #690953 - Partition name support


2)  Minimize label confusion using single properties dialog

If we place both the File System (Volume) Label, and the Partition
Label in a single dialog, then this will help distinguish between the
two types of labels.  We believe this will be less confusing to
GParted users.


3)  The "Partition" sub menu is growing quite large

Rather than simply adding another sub menu to the Partition menu for
setting Partition Labels, we have an opportunity to choose a different
approach.  More specifically we can migrate some menu item handling to
a single "Properties" dialog.

This change will remove the following menu entries under the Partition
menu:
   Format to
   Label
   New UUID


4) The Re-Format operation does not support labelling

The current "Partition --> Format to" menu only permits reformatting
the file system, but not specifying a volume label at format time.
While there are other ways to address this shortcoming (for example
add a new format dialog), we can also fix this problem with a shared
Properties Dialog.


In addition to the above reasons, longer term we can investigate
making "Manage Flags" into a queuable operation, and then placing this
in the Partition Properties dialog.  Currently "Manage Flags"
immediately writes the changes in partition flags when exiting the
dialog.


Mike,

What are your thoughts on this approach?

Doh!  Posted comment #7 to the wrong bug report.  ;(

Will repost in the correct report.  Specifically,

Bug #691681 - Improve Partition Info dialog to be Partition properties dialog

Hi Sinlu and Mike,

For the past while this enhancement has been stalled out, and I have
been wondering to myself why this is.  Being the project leader I
blame myself for this, and hence have tried to figure out how this
came to be.  Following are my thoughts on what went wrong, and
suggestions to get back on track.


WHAT WENT WRONG (THE STORY)
===========================

The addition of partition name support originally started when Sinlu
proposed the following enhancement.

Bug #690953 - Partition name support

My concern at the time was that users could get confused between
volume labels (which GParted supports), and partition labels (which
are the subject of the enhancement).  The confusion would arise
because GParted incorrectly refers to volume (or file system) labels
as partition labels.

Two suggestions for addressing this were suggested, and after
discussion it was decided that a Partition Properties dialog would be
the preferred method of implementation.


WRONG TURN 1
------------
With the realization of the clash between label names, we should have
addressed the layout of the Partition Information dialog at this time
to address the confusion.


In the report I noted that there was an existing problem that the
Re-Format operation did not support labelling and suggested that we
could fix this at the same time.

WRONG TURN 2
------------
The addition of a Re-Format operation to a Partition Properties dialog
was not well thought out.  In hindsight I think we should have left
this problem until later; however, we might not have learnt this
without the work-in-progress patch prototype.


From here a new bug report was created to convert the Partition
Information dialog into a Partition Properties dialog.

Bug #691681 - Improve Partition Info dialog to be Partition properties
              dialog

Many patches were written to implement the Partition Properties.  Some
of the problems with the patch set, such as loss of history because at
one time the information dialog was not renamed, were later
addressed.


WRONG TURN 3
------------
We tried to include too much all at once.  For example in addition to
converting from an Information dialog to a Properties dialog, we added
the partition name change, and re-format operation.


We continued work on this change with some less than clear
communication.


WRONG TURN 4
------------
Clear communication should have been made by me on how the Properties
dialog should work.  Partly as a consequence the patches submitted
were not as well tested as they should have been.  This also resulted
in more testing by reviewers thus consuming more time which could have
been more productively spent.


Again we continued working on this change.

WRONG TURN 5
------------
We continued changing the patch set before we had landed the GUI
layout.  Ideally we should have agreed on the GUI layout early on.
Having said that I think that our prototyping helped flush out the
final layout.


We agreed that 800x600 would be our minimum target screen resolution.
From here we continued building on the patch set.


WRONG TURN 6
------------
The patch set is now large, adds and removes functionality such as
re-format, and is difficult to review.


In conclusion some good has come out of this process.  For instance
developing this patch set has helped to arrive at some standards and
layouts.  On the downside though, the resulting patch set does not
represent a clean implementation of the changes needed to take the
dialog from Partition Information to Partition Properties.



SUGGESTION TO GET BACK ON TRACK
===============================

I think to get this enhancement back on track we should consider the
existing patch set as a prototype only.  By this I mean that we should
create a new patch set that implements changes in the following
manner:

1)  Create a patch to re-organize the existing Partition Information
    dialog so that it matches with our agreed GUI layout.

2)  Review, rework if necessary, and approve this patch/set.

3)  Create a patch to convert the Partition Information dialog into
    a Partition Properties dialog.  Note that only existing
    functionality should be converted, such as volume labelling and
    setting a new UUID.  The "Partition --> Label" and "Partition -->
    New UUID" menu option retirement should be one part of this patch
    set.

4)  Review, rework if necessary, and approve this patch/set.
    At this point this report can be closed.

5)  Use "bug #690953 - Partition name support" to create a new patch
    that adds Partition Name support.

6)  Review, rework if necessary, and approve this patch/set.
    At this point bug #690953 can be closed.



Mike and Sinlu,

Does this sound like a reasonable approach to get this enhancement
going again?

Please feel free to comment on what might be right or wrong with my
suggestions.

Curtis

Oops!  I meant to post this in the other related bug report.

Curtis

Thank you Sinlu for all your work to provide support for GPT partition names.  Your efforts enabled us to see the path forward.  :-)

Best regards,
Curtis Gedak

*** This bug has been marked as a duplicate of bug 741424 ***