> The compatibility issue between linux exfat and exfat of some camera company was reported from Florian. In their exfat, > if the number of files exceeds any limit, the DataLength in stream entry of the directory is no longer updated. So some files > created from camera does not show in linux exfat. because linux exfat doesn't allow that cpos becomes larger than > DataLength of stream entry. This patch check DataLength in stream entry only if the type is ALLOC_NO_FAT_CHAIN and > add the check ensure that dentry offset does not exceed max dentries size(256 MB) to avoid the circular FAT chain issue. Instead of using fsd to handle this, shouldn't it be left to fsck? In the exfat specification says, the DataLength Field of the directory-stream is the entire size of the associated allocation. If the DataLength Field does not match the size in the FAT-chain, it means that it is corrupted. As you know, the FAT-chain structure is fragile. At runtime, one way to detect a broken FAT-chain is to compare it with DataLength. (Detailed verification is the role of fsck). Ignoring DataLength during dir-scan is unsafe because we lose a way to detect a broken FAT-chain. I think fsd should check DataLength, and fsck should repair DataLength. As for the 256MB check, I think it would be better to have it. BR --- Kohada Tetsuhiro <Kohada.Tetsuhiro@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
