f_unlink Bug In FATFS (R0.12c)

[MatthewHoworko]

Hi everyone,

The version of FATFS (R0.12c) included in the latest H7 firmware package has a known bug in the f_unlink function which causes lost clusters on fragmented files of exFAT volumes. This results in the memory filling up, even if all files are deleted using f_unlink.

The bug was introduced in R0.12c, and fixed in R0.13a as documented at FatFs - Updates and Migration Notes. However, this newer version is not included in the firmware package.

From what I understand, migrating to a new version can involve updating the lower level code in the IO layer to match the newer FATFS versions.

Does anyone have experience migrating the included FATFS code manually? Would simply updating the code for f_unlink be a suitable option?

Thank you,

Matt

[Tesla DeLorean · Accepted solution]

I've been complaining about the staleness of the provided FatFS for years.

It's not hard to migrate the DISKIO layer, should mostly be doable with WinMerge or similar.

Couple of things with defines for versions, and some functions like f_size() and the time stamp. More tedious than anything. I think ST just chose to deprecate FatFS for File-X, perhaps to avoid licensing/patent issues.

I don't think it's just f_unlink(), I had other integrity checking failures when simply filling very large FAT32 / EXFAT volumes with 0.12c, think 200 / 400 GB devices