1

I know there is no difference between MS-DOS FAT32 and Windows FAT32 file system and there are only FAT16 and FAT32 but Disk Utility identifies FAT differently and in my case USB drive with Windows FAT32 is unreadable. The latter was created in Ubuntu when I wanted to make GParted live USB using:

sudo dd if=/path-to-gparted-live.x.y.z-w.iso of=/dev/sde bs=4M; sync

before that USB drive was formatted in disk utility to MS-DOS FAT32.

MS-DOS FAT32

and here is the picture of it after creating live USB in Ubuntu:

Windows FAT32

Why macOS doesn't read Windows FAT32?

  • 1
    You probably grafted an Hybrid-ISO MBR type disk to a GUID partition table with one type-FAT32 partition! The iso itself has ~three partitions: Apple_UDF/GParted-EFI/Apple_UDF//ISO9660/Apple_Free (check hdiutil imageinfo /path/to/gparted-live.x.y.z-w.iso . The thumb drive's partition map and file systems is/are broken now. – klanomath Dec 4 '17 at 21:30
  • @klanomath, I scanned partition table of that ISO and it had MBR: MBR only and GPT: GPT present. – Peter Dec 5 '17 at 10:10
2

You are copying a file to a block device. Let us consider the two.

A file is usually stored in a file system. The file is broken up to equal size blocks and generally stored non contiguously. The file system contains a table that links the blocks together.

Block devices also contain equal sized blocks. When the block device is an actually a physical device, such as a USB flash drive, these blocks are stored contiguously. Since the blocks are contiguous, there is no need for a table containing links.

Now, there are virtual block devices that are not physical devices, but rather are actually files themselves. Stored somewhere in these files is all the information needed to represent a physical block device. Also, these files may contain additional information needed to describe the physical device. An iso file is this type of file.

Block devices generally contain a table which define contiguous blocks called partitions. Not all block devices have such tables. File systems are usually stored in these partitions. Again, not all files systems require a partition container and partitions do not contain file systems exclusively.

Initially, the 16GB USB flash drive contained a partition table. This table had an entry that allowed for a FAT formatted file system to reside contiguously on most (if not all) of the remaining blocks.

The command you entered completely overwrote this partition table and partially overwrote the file system. In other words, the iso file was copied sequentially to the flash drive starting a the first block of the drive.

The end result? Well, the disk utility (actually macOS) thinks there is at least one partition on the USB drive and that this partition should contain a Windows_FAT_32 file system. Of course, this is wrong, but this what was interpreted from results of your dd command.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .