summaryrefslogtreecommitdiff
path: root/README.Windows
diff options
context:
space:
mode:
authorsrs5694 <srs5694@users.sourceforge.net>2010-02-04 00:55:30 -0500
committersrs5694 <srs5694@users.sourceforge.net>2010-02-04 00:55:30 -0500
commit6699b01eda84d24bfaf80ad725304fef2b0e1b2a (patch)
treed1bdfd45d748bdc1a87b45dcd043c51e75ab6945 /README.Windows
parent20e2a97ae67f2bbe31b354255671b3aed3793ee3 (diff)
downloadsgdisk-6699b01eda84d24bfaf80ad725304fef2b0e1b2a.tar.gz
Version 0.6.3 release. Big-endian bug fix, new GUID generation method,
architectural changes.
Diffstat (limited to 'README.Windows')
-rw-r--r--README.Windows9
1 files changed, 9 insertions, 0 deletions
diff --git a/README.Windows b/README.Windows
index a88d29d..91074c4 100644
--- a/README.Windows
+++ b/README.Windows
@@ -70,6 +70,15 @@ support of GPT, see Microsoft's Web page on the topic:
http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx
+The GUIDs generated by the program to uniquely identify disks and
+partitions aren't "proper" GUIDs; they're purely random numbers. In
+practice, this has caused me no problems; however, it's conceivable that
+some disk utility will complain. The Unix versions of GPT fdisk generate
+proper GUIDs, as of version 0.6.3. Note that this limitation applies ONLY
+to the unique GUIDs for disks and partitions, not to the GUIDs used to
+identify partition type codes; those are standardized and are handled
+correctly by all versions of GPT fdisk.
+
Source Code and Compilation Issues
----------------------------------