Cannot reliably mount emulated storage under Linux

[JakubVanek]

See microsoft/pxt-ev3#980

The dynamically-generated F_UF2 entries somehow cause mounting problems.

[JakubVanek]

I think I have finally found it. Comparing the dumped file to the description on Wikipedia, there are multiple problems:

1. Volume label directory entry (EV3) does not have cluster number set to zero.
2. The cluster corresponding to the Projects directory table has the next cluster == 0x0000 (FREE), instead it should be 0xFFFF (EOF). (however see below, this may be caused by Linux).
3. Linux requires a directory table to have at least two directory entries (https://github.com/torvalds/linux/blob/aeb542a1b5c507ea117d21c3e3e012ba16f065ac/fs/fat/inode.c#L497), which is not fulfilled there. The directory table contains only the DEMO.UF2 directory entry, which is not enough. There should be also the . and .. directories present. I think this may cause the issue above - when Linux detects this, it sets the next cluster pointer to zero.
4. The dmesg.txt file has 512 blocks allocated in the FAT, but its directory entry lists it as only 256 blocks long.

[JakubVanek]

Fixing just (2) and (3) in the dumped image is enough to make the drive mountable without problems. The solution is to add valid . and .. directory entries to the Projects directory table.

[JakubVanek]

Problem no. 4 found:

uf2-linux/uf2daemon/fat.c

Line 559 in c003d65

c->numclusters = (c->st.st_size + 255) / 256;

(I think this should be 511/512).

EDIT: I am likely wrong with this, as it seems that the block size is supposed to be 256 bytes for passthrough files:

uf2-linux/uf2daemon/fat.c

Lines 334 to 337 in c003d65

	if (c->flags & F_RAW)
	c->numclusters = (c->st.st_size + 511) / 512;
	else
	c->numclusters = (c->st.st_size + 255) / 256;

[JakubVanek]

Problem no. 1 maybe spotted:

It would seem to me that startCluster is what can be seen in the generated directory entry. Currently, it is set to the "current cluster", not to 0x0000.

It seems that UF2Daemon generates this correctly, but as soon as the Linux kernel mounts the FS, it sets the FAT entries to zero.

[lfrie]

when is this fixed? i have the same issue

[JakubVanek]

I'm sorry but I currently don't have much time to work on this. Also, fixing this here would fix the problem only for new releases of uf2d (which is the first step though); it would then have to be fixed with a firmware update for the problematic device (if your device is not fully under your control like with Raspberry Pi).