FAT32 'FS Information Sector' contents relied on blindly, even if 'unclean shutdown' flagged

[tgipsonMIDE]

Describe the bug
An improperly dismounted FAT32 filesystem may report incorrect values in the 'FS Information Sector' (notably # of free clusters), despite the sector being present and having a correct signature. There is a 'clean shutdown' bit that, if clear, indicates the disk wasn't closed cleanly and the FSInfo values are unreliable, however, FileX doesn't appear to test or honor this bit. Instead, it blindly uses the FSInfo values as truth, and if starting with an erroneous value, the value written back on closing the FS will continue to be erroneous. An example outcome is failure to write new data (reporting 'disk full') even if there is plenty of space left. _fx_media_open() does include a routine to recompute the correct FSInfo values, but it is only triggered by egregious errors in the FSInfo contents, not the clean-shutdown flag, and cannot be manually forced by the implementor.

Please also mention any information which could help others to understand
the problem you're facing:

• What target device are you using? STM32U
• Which version of Eclipse ThreadX? The downstream STM32 fork of FileX (https://github.com/STMicroelectronics/stm32-mw-filex), however the behavior is inherited from and present in the current Eclipse FileX.
• What toolchain and environment? STM32CubeIDE 1.18.1, GNU Tools for STM32 (13.3.rel1)
• What have you tried to diagnose or workaround this issue? Produce a test disk image where our device fails with an 'insufficient free disk space' error code despite a Windows PC reporting ~7GB free. Place HW breakpoints in fx_media_open() line ~ 671, where fx_media_available_clusters is initialized, and observe a very low value is being read and used without further checking.

To Reproduce
Steps to reproduce the behavior:

1. Introduce bogus values for available clusters and (optionally) last available cluster in the FAT32 Additional Info structure and clear the 'clean shutdown' flag, e.g. by directly modifying the sectors (for testing), or yanking removable media during a write. In the latter case ensure the Additional Info values are indeed out of sync.
2. Write to the volume using FileX until the disk is reported as full.
3. Observe the disk is not actually full as reported by other FS hosts.

Expected behavior
*Validity check of the Additional Info values (e.g fx_media_available_clusters) is conditional on the clean shutdown flag; error conditions flagged there invalidate the Additional Info and trigger recomputation of these values.
*Implementer option to manually force recomputation during fx_media_open()

• Use (clear/set) clean shutdown bit so that unclean removals from FileX can be detected during fx_media_open()

Impact
Customer-reported issues and returns; customers receive a baffling error code and cannot use our device or fix the problem themselves. To complicate the issue, most customers use Windows and would use chkdsk.exe to repair filesystem errors, however in our testing (Windows 10) chkdsk.exe /f does not correct the Additional Info values even if it makes other corrections to the filesystem.

Logs and console output
If applicable, add console logs or other types of debug information like Wireshark capture as .zip file.

Additional context
See above, recent (at least) versions of the Windows chkdsk utility do not fix the Additional Info values, leaving end users no easy way to fix the problem themselves.

[fdesbiens]

Hi @tgipsonMIDE.

Thank you for submitting this issue. I will bring it to the team's attention.

[rahmanih]

Hi @tgipsonMIDE,
which storage media did you use? (uSD, thumb key..)?

regards
Haithem.