On Thu, 13 Feb 2020 16:18:47 -0500, Sasha Levin said: > >> I was hoping that it would be possible to easily use secondary FAT table > >> (from TexFAT extension) for redundancy without need to implement full > >> TexFAT, which could be also backward compatible with systems which do > >> not implement TexFAT extension at all. Similarly like using FAT32 disk > >> with two FAT tables is possible also on system which use first FAT > >> table. OK.. maybe I'm not sufficiently caffeinated, but how do you use 2 FAT tables on a physical device and expect it to work properly on a system that uses just the first FAT table, if the device is set to "use second table" when you mount it? That sounds just too much like the failure modes of running fsck on a mounted filesystem.... > >By the chance, is there any possibility to release TexFAT specification? > >Usage of more FAT tables (even for Linux) could help with data recovery. > > This would be a major pain in the arse to pull off (even more that > releasing exFAT itself) because TexFAT is effectively dead and no one > here cares about it. It's not even the case that there are devices which > are now left unsupported, the whole TexFAT scheme is just dead and gone. > > Could I point you to the TexFAT patent instead > (https://patents.google.com/patent/US7613738B2/en)? It describes well > how TexFAT used to work. I don't think anybody wants the full TexFAT support - but having a backup copy of the FAT would be nice in some circumstances. Actually, that raises an question.... What the published spec says: The File Allocation Table (FAT) region may contain up to two FATs, one in the First FAT sub-region and another in the Second FAT sub-region. The NumberOfFats field describes how many FATs this region contains. The valid values for the NumberOfFats field are 1 and 2. Therefore, the First FAT sub-region always contains a FAT. If the NumberOfFats field is two, then the Second FAT sub-region also contains a FAT. The ActiveFat field of the VolumeFlags field describes which FAT is active. Only the VolumeFlags field in the Main Boot Sector is current. Implementations shall treat the FAT which is not active as stale. Use of the inactive FAT and switching between FATs is implementation specific. Sasha: can you find out what the Windows implementation does regarding that last sentence? Does it actively use both FAT sub-regions and switch between them (probably not), or does it read the ActiveFAT value and use that one, or does Windows just use NumberOfFats == 1? I'm assuming that the fact the doc also says "NumberOfFats == 2 is only valid for TexFAT volumes" possibly means "Microsoft thinks that's hardcoded at 1" given the death of TexFAT. That would make adding alternate FAT support a major challenge. On the other hand, if Windows actually looks at the NumberOfFats value, finds a 2, and ActiveFAT ==1 (meaning use second table) and says "OK, whatever" and just uses the second table from there on out, it becomes a lot easier.
Attachment:
pgpsy23hF8jSB.pgp
Description: PGP signature
