rahul dev wrote: ... >> Has this code caused an actual problem for you? > > One more question here. > Should we allow read of gpt table in case the header size > 92 ? This > is because if the header size has been increased, the header revision > should also be increased. So, we should fail reading such a partition > table (saying hdr revision not supported). > Even if allow reading such a table, we should not allow any > modifications to it. While writing the gpt header we modify the header > size, so original contents (beyong 92 offset) will be > lost/overwritten.
I think parted must accept header size > 92. Currently parted can usefully read partition tables like the one you mention below. > I am seeing this problem for gpt partitions created by Solaris "zpool > create" command. It creates a gpt hdr with size 512 bytes (but doesn't > change the revision which is incorect). Apart from this it has only 9 > partition table entries (which doesn't comply with the EFI > spec). Moreover, it doesn't place the backup gpt at the end of > disk. Using libparted, I can read this table. But, if I modify such a > table the original gpt hdr contents are lost. > > I feel that we should fail both read/write of a table whose hdr size > > 92. What's your opinion ? Reading such a partition table must be possible. Like any writing operation, one should be careful to save backups. I guess in this case, parted could issue a diagnostic about the mismatch. However, I feel strongly that even the possibility of a write operation (even after a prompt that asks if it's ok) during a nominally read-only task, should be eliminated. For example, currently just listing a GPT partition table may lead to parted asking you if you'd like to reposition the backup header. That happens only when not using -s. Having a separate option to repair a partition table would be fine. Having that option enabled during a read-only operation like "list" is not.
