Disk Utility deletes my Windows EFI partition
Solution 1:
I do not understand your justification for having two EFI partitions. Since you have stated both Windows and Linux are using the first EFI partition to boot, then there is no reason for having the second EFI partition. Most likely if you eliminated the second EFI partition, then the Disk Utility would not be deleting the first EFI partition.
Both the Disk Utility application and diskutil command are complex software developed by Apple to simplify the most disk management tasks. (Here a disk could be a HDD, SSD, USB drive, image file such as .dmg or .sparseimage, image folder such as .sparsebundle, etc...) Using either is a learned experience. In your case, you learned something the Disk Utility application can not do as expected. Or, can not do as expected with your version of macOS. I suppose in the future you should avoid this problem by using newfs_exfat command instead.
Update Regarding Your Triple Boot
When the Boot Camp Assistant is used to install UEFI booting Windows for a dual boot arrangement, the existing EFI partition is used for the Windows boot files. This EFI partition is 209.7 MB (409,600 sectors) when the sector size is 512 bytes and 314.6 MB (76,800 sectors) when the sector size is 4096 bytes. Since you are also installing an UEFI booting Linux and have a sector size of 512 bytes, an EFI partition of around 300 MB should be sufficient. I feel an increase to 300 MB is more that enough, since the boot files in the EFI partition for Ubuntu on my iMac only use about 9.8 MB.
Update Regarding the Behavior of Disk Utility and diskutil
Below is the diskutil list disk1 output from a disk image. If you do not know, a disk image is a file or folder which can be mounted as drive.
$ diskutil list disk1
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +4.0 GB disk1
1: EFI EFI 104.9 MB disk1s1
2: EFI EFI 209.7 MB disk1s2
3: Microsoft Basic Data MYFAT32 3.7 GB disk1s3
If I try to use the Disk Utility to format disk0s3 as ExFAT, I will get the following error message. I have learned this is caused by the first EFI partition being to small.
If the diskutil command is used to format disk1s3 as ExFAT, a similar message appears, as shown below.
$ diskutil erasevolume exfat MyExFAT disk1s3
Started erase on disk1s3 MYFAT32
Unmounting disk
Error: -5344: MediaKit reports not enough space on device for requested operation
Next, the first EFI partition is removed, as shown below.
$ diskutil erasevolume free none disk1s1
Started erase on disk1s1 EFI
Unmounting disk
Finished erase on disk1
$ diskutil list disk1
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +4.0 GB disk1
1: EFI EFI 209.7 MB disk1s2
2: Microsoft Basic Data MYFAT32 3.7 GB disk1s3
Now the Disk Utility works, as shown below. Since first EFI partition is now large enough, the operation succeeds.
If the same also succeeds with using the diskutil command, as shown below.
$ diskutil erasevolume exfat MyExFAT disk1s3
Started erase on disk1s3 MyExFAT
Unmounting disk
Erasing
Volume name : MyExFAT
Partition offset : 614440 sectors (314593280 bytes)
Volume size : 7198067 sectors (3685410304 bytes)
Bytes per sector : 512
Bytes per cluster: 32768
FAT offset : 128 sectors (65536 bytes)
# FAT sectors : 896
Number of FATs : 1
Cluster offset : 1024 sectors (524288 bytes)
# Clusters : 112453
Volume Serial # : 61a3d821
Bitmap start : 2
Bitmap file size : 14057
Upcase start : 3
Upcase file size : 5836
Root start : 4
Mounting disk
Finished erase on disk1s3 MyExFAT
$ diskutil list disk1
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +4.0 GB disk1
1: EFI EFI 209.7 MB disk1s2
2: Microsoft Basic Data MyExFAT 3.7 GB disk1s3
Next, the remaining EFI partition is removed, as shown below.
$ diskutil erasevolume free none disk1s2
Started erase on disk1s2 EFI
Unmounting disk
Finished erase on disk1
$ diskutil list disk1
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +4.0 GB disk1
1: Microsoft Basic Data MyExFAT 3.7 GB disk1s3
Now, there are no EFI partitions. One would expect both the Disk Utility and diskutil to fail when trying to format this last partition. However both succeed, as shown below.
Note, the output below shows the Disk Utility also created a new EFI partition.
$ diskutil list disk1
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +4.0 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Microsoft Basic Data MyExFAT 3.7 GB disk1s3
Before trying the diskutil erasevolume exfat MyExFAT disk1s3 command, this new EFI partition is removed, as shown below.
$ diskutil list disk1
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +4.0 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Microsoft Basic Data MyExFAT 3.7 GB disk1s3
$ diskutil erasevolume free none disk1s1
Started erase on disk1s1 EFI
Unmounting disk
Finished erase on disk1
$ diskutil list disk1
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +4.0 GB disk1
1: Microsoft Basic Data MyExFAT 3.7 GB disk1s3
$ diskutil erasevolume exfat MyExFAT disk1s3
Started erase on disk1s3 MyExFAT
Unmounting disk
Erasing
Volume name : MyExFAT
Partition offset : 614440 sectors (314593280 bytes)
Volume size : 7198067 sectors (3685410304 bytes)
Bytes per sector : 512
Bytes per cluster: 32768
FAT offset : 128 sectors (65536 bytes)
# FAT sectors : 896
Number of FATs : 1
Cluster offset : 1024 sectors (524288 bytes)
# Clusters : 112453
Volume Serial # : 61a3ea2c
Bitmap start : 2
Bitmap file size : 14057
Upcase start : 3
Upcase file size : 5836
Root start : 4
Mounting disk
Finished erase on disk1s3 MyExFAT
$ diskutil list disk1
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +4.0 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Microsoft Basic Data MyExFAT 3.7 GB disk1s3
Note, a new EFI partition was also created. Clearly, both the Disk Utility and diskutil are doing more thinking that simply formatting a partition.
In all of the above cases, the newfs_exfat -v MyExFAT /dev/rdisk1s3 command would have succeeded on an unmounted disk1s3, since this command does require the existence of any EFI partitions.