什么是UDF的分区ID /文件系统types？

答案是分区types06（FAT16）。 不要问我为什么问微软。

事实certificateUDF没有分区表，并且没有分配给它的分区ID。 这个文件系统必须跨越整个磁盘才能被Windows识别。 将UDF格式化为硬盘不会触及现有的分区表（小心 – 它将包含陈旧的信息，如果使用它装入驱动器，则会破坏数据！）。

好奇心 – UDF 2.5和更高版本为元数据创build单独的分区（每个磁盘一个或两个）。 但是，这些分区在标准DOS分区表中也是不可见的。

在我处理的CD和DVD上，没有分区表。 在您的USB硬盘驱动器上，您已经向介质写入了分区表。 我怀疑，如果您将整个驱动器格式化为不带分区表的UDF磁盘，Windows将无法安装它。

你不会说什么大小你的USB驱动器，你可能不愿意把整个驱动器作为UDF专用，你可以尝试设置分区types与fdisk作为NTFS或其他MS支持的types之一。

简短的回答：我会build议使用UDF分区的MBR ID 0x07 。

很长的回答：

Linux不关心MBR分区ID并忽略它（*）。

当且仅当IsRecognizedPartition（PartitionType）为true时，Windows 2000和更新版本才能为id为PartitionType的某个分区分配驱动器号。 此外，对于非FT分区，必须保证IsFTPartition（PartitionType）为false（否则该分区被检测为FT，而不是普通的FAT / NTFS / UDF / …）。

条件IsRecognizedPartition（PartitionType）&&！IsFTPartition（PartitionType）适用于这些MBR分区ID： 0x01，0x04，0x06，0x07，0x0B，0x0C，0x0E （**）。 这意味着如果MBR分区ID是其中之一，则Windows 2000（和新的）可以识别和使用UDF分区。 可能没有其他的限制，任何受支持的文件系统都会接受任何这些MBR ID的分区。 这意味着这些MBR ID不用于检测文件系统。

但是，当使用特定的PartitionType时，Microsoft有一些build议 ：

• 0x01 – FAT12主分区或逻辑驱动器（卷中less于32,680扇区）
• 0x04 – FAT16分区或逻辑驱动器（32,680-65,535扇区或16 MB-33 MB）
• 0x06 – BIGDOS FAT16分区或逻辑驱动器（33 MB-4 GB）
• 0x07 – 可安装文件系统（NTFS分区或逻辑驱动器）
• 0x0B – FAT32分区或逻辑驱动器
• 0x0C – 使用BIOS INT 13h扩展的FAT32分区或逻辑驱动器（***）
• 0x0E – BIGDOS FAT16分区或使用BIOS INT 13h扩展的逻辑驱动器（***）

微软还意味着 ：

• 0x01 – 指定具有12位FAT条目的分区。
• 0x04 – 指定具有16位FAT条目的分区。
• 0x06 – 指定一个MS-DOS V4巨大的分区。
• 0x07 – 指定一个IFS分区。
• 0x0B – 指定一个FAT32分区。
• 0x0C – Windows 95/98：指定使用扩展INT 13服务的分区。

在Wikipedia上也可以find一些build议：

• 0x01 – CHS / LBA – DOS 2.0+ – FAT12作为第一个物理32 MB磁盘的主分区…（否则使用0x06代替）
• 0x04 – CHS / LBA – DOS 3.0+ – FAT16less于65536扇区（32 MB）…（否则使用0x06代替）
• 0x06 – CHS / LBA – DOS 3.31+ – 具有65536个或更多扇区的FAT16B。 它必须驻留在第一个物理8 GB的磁盘中（否则使用0x0E）。 如果主分区不在第一个物理32 MB磁盘中，也用于主分区中的FAT12和FAT16卷。
• 0x07 – CHS / LBA – OS / 2 1.2+，Windows NT / CE – IFS / HPFS / NTFS / exFAT / QNX
• 0x0B – CHS / LBA – DOS 7.1+ – 带CHS寻址的FAT32
• 0x0C – LBA – DOS 7.1+ – 带有LBA的FAT32
• 0x0E – LBA – DOS 7.0+ – 带有LBA的FAT16B

要完成id列表，这里是关于不支持UDF格式的硬盘分区的旧系统的一些信息。

Windows NT 4.0及更早版本可以将驱动器号分配给MBR ID为0x01,0x04,0x06,0x07的分区。

基于DOS的Windows（95,98和ME）只能将驱动器号分配给MBR ID为0x01，0x04，0x06，0x0B，0x0C，0x0E的分区。 MS-DOS本身只能访问MBR ID分区：0x01,0x04,0x06。 请注意，这些系统使用MBR分区ID来检测文件系统。 MBR分区ID必须与分区上的文件系统匹配。

结论：

查看分区大小：0x01和0x04应该只用于第一个32MB磁盘中的分区。 只有在第一个8GB的磁盘0x06。 CHS寻址的地址是0x8B，对8GB磁盘有限制。 所以没有这样的限制，只有ID：0x07，0x0C和0x0E。 由于0x0C和0x0E用于FAT分区，我build议select0x07 。 这意味着IFS（可安装文件系统）分区，根据维基百科，微软将对UDF的支持添加到了Windows 2000 IFS API中。 使用0x0C或0x0E会导致基于DOS的系统将该分区显示为FAT，即使它将被格式化为UDF。 MBR id 0x07的分区隐藏在这些系统上。 它们不支持UDF，所以最好select0x0C或0x0E。

GPT：

GPT分区布局不是这个问题，但它与MBR有类似的问题。 没有为UDF分配的分区GUID（与MBR id等效的GPT）。 由于Windows XP x64支持UDF，并且只能使用GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 （Microsoft基本数据分区）识别GPT数据分区，所以它是GPT唯一可能的select。

资料来源：

• https://technet.microsoft.com/en-us/library/cc976786.aspx
• https://technet.microsoft.com/en-us/library/cc768180.aspx
• https://technet.microsoft.com/en-us/sysinternals/ff563751
• https://technet.microsoft.com/en-us/sysinternals/aa363990
• https://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us/resguide/diskover.mspx
• https://en.wikipedia.org/wiki/Partition_type
• https://en.wikipedia.org/wiki/Installable_file_system
• 文件Ntdddisk.h（WinDDK的一部分）
• 文件WinIoCtl.h（WinSDK的一部分）

_{（*）有一个例外：MBR ID 0x05，0x0F和0x85用于检测扩展MBR分区。
（**）这两个调用的定义可以在WinIoCtl.h文件中find，因为它们被声明为Cmacros。
（***）BIOS INT 13h扩展意味着使用LBA而不是CHS。}

我有同样的问题。 我的USB硬盘是320GB。 分区表看起来像这样：

Disk /dev/sda: 320.0 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x44fdfe06 Device Boot Start End Blocks Id System /dev/sda1 * 1 27963 224612766 c W95 FAT32 (LBA) /dev/sda2 27964 38913 87955875 5 Extended /dev/sda5 27964 33366 43399566 7 HPFS/NTFS /dev/sda6 33367 38913 44556246 83 Linux 

分区sda5是一个UDF版本。 1.5和肩膀是可读的Windows XP及以上。 Linux当然会正确读取它。 然而Windows是困惑的。 它将分区识别为NTFS，然后假定它是原始分区。

我在pendrive的UDF实验表明，系统往往把UDF与FAT错误。 他们把UDF解释为FAT。 它必须是相当大的相似之处，因为我可以看到随机字符的目录结构。 Linux说磁盘已损坏，但并不拒绝使用它。

我认为UDF（至lessrev 1.5）在USB驱动器上不被很好的支持。