[parted-devel] Copyright assignment form for parted

[Phil Susi]

On 9/25/2015 12:40 AM, Al Dunsmuir wrote:
> On Thursday, September 24, 2015, 9:15:52 AM, Phil Susi wrote:
>> < let's keep this on the list >
> Sorry... my email client defaulted to your direct email.

Get in the habit of using reply-to-all.  You want all of those on the Cc
list to stay on the Cc list unless you have a darn good reason for
excluding them from the conversation going forward, and I didn't see
this reply until now because I didn't get the direct reply and don't
check all of my mailing lists every day.

>> How would such a thing make any sense?  It isn't a filesystem.  You
>> can't have it on a non APM partitioned disk; it only has meaning in
>> conjunction with the partition table.  Any checking of it should be done
>> by a partitioning tool accessing the raw disk instead of the partition.
> 
> I'm  not  sure  in which area(s) I'm not making sense.  I'm not saying
> they don't exist 8^), merely that I'm not clear in my understanding.
> 
> The  map  partition  is not hidden on OS/X, and deciding to hide it on
> Linix at this point in time seems like more trouble than it is worth.
> 
> I'm  treating  it  as a filesystem that is only valid for mac volumes,
> and  in  fact  is  mandatory  for  mac  volumes. It gets automatically
> created  when the mac volume is created, and must be kept in sync with
> events such as creation, deletion, or movement of any other partitions
> on the mac volume.

What I am saying is that it is not a filesystem at all, and can not be
checked on its own, independent of the main partition table.  That is,
if you dd'd your map partition to a partition onto a GPT partitioned
disk, you couldn't fsck it.

> Swap  isn't  a  much  more  complex filesystem, but libparted supports
> multiple type (3 Linux variants, and I believe 1 BSD). This goes along
> with the "swap" flag.

Yes, but you can choose to have a swap partition or not ( or multiple
ones ), and swap is still swap no matter what partition type it is in,
and it can be mounted.  With the map partition, there can be one and
only one, and only for a mac partitioned disk, and its contents are
useless to anything but a mac partition table editor.

>> Speaking of that, doesn't blkid already identify the usage type of this
>> partition correctly and gparted could use that?
> 
> blkid returns PARTLABEL="Apple". meh.

Even blkid -p /dev/sda?  It should indicate ID_FS_USAGE...

> lsblk  (the  new  utility  the  udev  developers  want  folks  to use)
> recognizes  it  as  partition  type  "Apple_partition_map",  and label
> "Apple".

That's just a user friendly frontend to blkid.  If it sees that
Apple_partition_map type, so should blkid and so gparted could use that.

> gparted  initially  uses  libparted to obtain partition and filesystem
> information.  It  defaults  to  allowing  deletion/reformatting of any
> partition  with an unknown type - OK from a brute force POV for simple
> partitions,  but  when the partition controls all the other partitions
> on the volume it becomes risky.

Come to think of it... even if gparted doesn't disable the deletion, why
the hell doesn't libparted refuse to do it and return an error code?  It
should at least do that.

> It  seems  like many tools expect active (and important) partitions to
> also  have  a  filesystem type.  Maybe it's a bad assumption, but that
> the way they tools are currently implemented.

Yes, but it lets other sources of information like blkid supersede that
provided by libparted.

> Having  libparted  mark  the Apple_partition_map partition with a flag
> called  "map" gives users useful info. Recognizing a "fake" filesystem
> type  of  "apple-map"  (with alias "Apple_partition_map") provides the
> rest.  Adding  a  few  lines  of  code  to  protect  against deletion,
> reformatting and changing the flags was very simple.
> 
> The  blivet  and  blivet-gui  packages  make use of libparted (through
> pyparted).   That's  my  main  interest,  so  I wanted to use the same
> source  of information.  blivet now also uses libblkdev, so I may need
> to add some code (plugin?) there too.

The problem I have is that this seems to be outside of the intended
usage for both filesystem type and flags.  The filesystem type is
supposed to identify which one of many filesystems is present in the
partition currently, and you can choose to format a different one there
at any time.  That isn't really so with the map partition.  The flags
are supposed to be special toggles that the user can flip when they need
to force a partition table specific behavior, that is irrespective of
any filesystem.  If the user can't set or clear the flag, then why have it?

Since they can't do anything with it, wouldn't it be much simpler and
less confusing to just not show the partition to the user in the first
place?

I suppose if it must be one or the other, it should be just the flag.
Why have both?  It also wouldn't make sense to report an apple partition
map filesystem found on a GPT disk, or to report a fat filesystem if you
found one in what is supposed to be the mac partition map partition
would it?