I missed that 10h byte! well spotted! I wonder if the volume is also WP in linux?
Naaah.
The reference given talks of "Linux data partition", but that GUID is actually that of a "Basic Data Partition":
http://en.wikipedia....Partition_Table
http://en.wikipedia...._data_partition
and Linux uses it only because there are (possibly "were") NO alternatives.
AFAICU, the good MS guys had to invent *something* for XP 64 bit booting with a GPT disk, and - not surprisingly in their good ol' tradition of re-using code for other scopes (thus breaking "standards" they themselves set earlier) - are re-using it to "confuse" their own Mount Manager that probably, not understanding if the disk is MBR or GPT decides - to be on the safe side - to mount all volumes on the disk as "Read Only".
Now if you call something "globally unique identifier" you would expect (at least lexically) that it is something similar to a volume (or device) serial , i.e. something that is unique to that particular volume (or device) why what they were able to express with one single byte (the partition ID) is now represented for - ALL volumes of a same kind - by a senseless 16 bytes sequence of bytes.
As a matter of fact, besides using 16 times the data, they also loose (definitely) some "resolution".
Till now (though not "certain" you could know that if a partition ID of 06 was in the MBR, then probably you had a FAT16 volume (and that should have been addressed through CHS) or if you had a 07 one it would have been probably a NTFS volume (HPFS are relatively rare), but recently they had already undermined this with exFAT using senselessly the same 07 ID, see:
http://www.forensicf...570136/#6570136
with GUID's they loose even the last remains of this probability to know in advance (without parsing the bootsector) the actual filesystem used on the volume.
We have now 16 bytes of data (that is 256^16 - i.e. zillions different possible values ) used to represent (currently) less than 100 (one hundred) different partition types.
Wonko