[parted-devel] Copyright assignment form for parted

[Al Dunsmuir]

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.

> On 9/23/2015 7:31 PM, Al Dunsmuir wrote:
>> Keeping  it visible would make it straight forward to create new tools
>> such  as a apple-map.fsck utility to validate the mac volume partition
>> map  and  contained  partitions.  Once  again,  GParted  would support
>> calling  that  "check"  function  with little additional fuss. The map
>> format is so simple (dumb == reliable), I suspect there is little real
>> demand  for  the  ability  to  repair  a  damaged map, only report any
>> issues.

> 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.

Sure  it's not a terribly interesting filesystem. It is really just an
array  of  512-byte  elements that describe all the active and deleted
partitions on the mac volume, including itself.

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.

There  are  a  few  checks  that  libparted  currently  performs  when
validating  the  Apple_parttiion_map partition. I've just incorporated
those in the "apple-map" filesystem probe code.

There are a very few additional checks  that could be done:
- verifying  that  all  sectors  on  the  volume  are accounted for in
  partition entries
- checking for overlapping partitions
- checking that all partition types are recognized
Writing  a  tiny  utility to check this would be straight forward, but
much lower in priority than other tasks.

One of the utilities that claims support for mac volumes is "disktype"
(from SourceForge). Upstream is present, but has not been under active
development  for a long time. Fedora has a version with a few patches.
It  had  a  few bugs (ran off the end of the partition list because it
forgot  that  the map partition occupies an active partition number. I
fixed  that  and added a bit more data output in a patch that I'd like
to get into the Fedora version.

>> The  existing  approach  for  other  "special"  partition types within
>> gparted  is to recognize them based on output from libparted and other
>> system   and   filesystem-specific   tools  -  blkid,  vol_id  (RIP  -
>> assimilated by udev (now systemd) and killed).

> 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.

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

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.

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.

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.

>> I  have  verified  using  gdb  that my libparted changes do return the
>> correct  sector  used/unuses  geometry  during the initial "apple-map"
>> fileystem probe (when called by parted). I've only supported the probe
>> function  for  now,  since  resizing the partition map is not terribly
>> useful. I modeled this after the "linux-swap" filesystem support.

> We only have the probe function these days -- all resize support was
> removed in parted 3.0.

It  will be interesting to see how gparted is determining the used and
unused  sector  values  for  a  partition  if  they  are not using the
geometry returned by the probe.

>> BTW,  Brian has EMail from me with links to the preliminary patches on
>> my web site. I can post here once I have the gparted changes complete.
>> I  am new to git (and GitHub), and so have getting familiar with those
>> as priorities so I can fit in the preferred development process.

> Indeed... it is a bit of a learning curve, but well worth it.
Indeed  - moving from abstract knowledge to working knowledge.

Al