< let's keep this on the list > 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. > 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? > 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. > 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.
