> > 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? Yes, That's what I thought at first. And fsck.exfat in exfatprogs can detect it like this. $ fsck.exfat /dev/sdb1 exfatprogs version : 1.1.1 ERROR: /DCIM/344_FUJI: more clusters are allocated. truncate to 524288 bytes. Truncate (y/N)? n > > 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. Yes. I have checked it. > > 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. But Windows fsck doesn’t detect it and it shows the all files normally without any missing ones. It means Windows exfat doesn't also check it in case type is ALLOC_FAT_CHAIN. > > As for the 256MB check, I think it would be better to have it. > > BR > --- > Kohada Tetsuhiro <Kohada.Tetsuhiro@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
