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?
