Re: [Info-mtools] [BUG] mcopy unable to copy to small FAT32 image starting v4.0.32

[Alain Knaff]

Hi,

On 19/08/2022 22:22, Alexander Bazarov wrote:
> Hi,
> 
> During image creation for an embedded device that has a stripped

Would it be possible to have more details about this embedded device?
Which make, maybe "official" example images, etc.



> version of driver for FAT32 only (fails to boot with FAT12/16)
> following step is performed and began to fail with newer versions of mtools:
> ```
> mkfs.vfat -C img.vfat 0x4000 -F 32 -S 2048 -s 32
> mcopy -v -i img.vfat anyfile.txt ::
> ```
> 
> I believe that mcopy auto detects it as FAT12/16 based on the number
> of clusters.

Actually, according to Microsoft's specification, number of FAT bits of
an existing filesystem is SOLELY determined by the number of clusters.
This applies to all *three* bit numbers: 12/16/32

However, *other* aspects of FAT32 (FAT size, location of root directory,
info block) are determined by whether the 16 bit fatlen boot sector
variable (offset 22) is 0 or not. If 0, the fat length (number of
sectors in FAT) is instead read from the ext.fat32.bigFat boot sector
location at offset 36. This also triggers the use of a freely placable
root directory (at cluster rootCluster at offset 44). At least that's
how it's supposed to happen with Microsoft's own operating systems,
although not yet completely implemented in mtools.

> Is there any option to force mcopy to treat the image as
> FAT32 ? (I didn't find any flag and using environment variable
> MTOOLS_SKIP_CHECK=1 doesn't help)

Older mtools had special flags which could be used to force a given FAT
type even if the number of clusters didn't match.

However, such filesystems are not "standard" conformant, and even
Windows (or MS-DOS) will make a mess out of them. That's why mtools no
longer supports this.

[...]
> for FAT16 it works:
> ```
> user@tmp/mtools-4.0.40/usr/bin$ mkfs.vfat -C img.vfat16 0x4000 -F 16
> -S 2048 -s 32
> mkfs.fat 4.1 (2017-01-24)
> WARNING: Not enough clusters for a 16 bit FAT! The filesystem will be
> misinterpreted as having a 12 bit FAT without mount option "fat=16".
> user@tmp/mtools-4.0.40/usr/bin$ ./mcopy -v -i img.vfat16 anyfile.txt ::
> Copying anyfile.txt
> ```

It works... but with this rather stern warning :-)

> 
> Any ideas how to solve or bypass the issue (other than forcing use of
> old mtools)?

I'm hesitant in bringing back this override (due to its incompatibility
with the intended target, namely windows and MS-DOS), and astonished
that there exist embedded devices which seem to require it.

I'm wondering whether there is maybe a possibility to operate this
device in a way that is also compatible with the FAT type selection rule
as implemented in windows. Some examples of filesystems (as supplied by
the creator of this embedded platform), and / or clear (googlable)
identification of it might help me come up with something.

Maybe the device would understand a FAT16 with a freely plaçable root
directory? (i.e. boot.fatlen is 0, but boot.ext.fat32.bigFat is not).

If so, I could add the missing logic for that to mtools.

Regards,

Alain