> > > > > > > >> + if (exfat_get_entry_type(ep) & TYPE_BENIGN_SEC) > > > >> + exfat_free_benign_secondary_clusters(inode, ep); > > > >> + > > > > > > > > Only vendor allocation entry(0xE1) have associated cluster > > > > allocations, vendor extension entry(0xE0) do not have associated > > > > cluster > > > allocations. > > > This is to free associated cluster allocation of the unrecognized > > > benign secondary entries, not only vendor alloc entry. Could you > > > elaborate more if there is any issue ? > > > > From exFAT spec, there are 2 types benign secondary entries only, > > Vendor Extension entry and Vendor Allocation entry. > > > > For different Vendor, Different Vendors are distinguished by different > > VendorGuid. > > > > For a better understanding, please refer to > > https://urldefense.com/v3/__https://dokumen.pub/sd-__;!!JmoZiZGBv3RvKR > > > Sx!-iaK3DSO2yh1pGjdOLoZjMhH7s6QEAbN-Yd05bnBzTzpPks10JNCptYbvAdHZ > XYYvox > > 5D4Pi2xC3TBqH1pHEIg$ > > specifications-part-2-file-system-specification-version-300.html. This > > is the specification that the SD Card Association defines Vendor > > Extension entries and Vendor Allocation entries for SD card. "Figure 5-3 : > > Continuous Information Management" is an example of an entry set > > containing a Vendor Extension entry and a Vendor Allocation entry. In > > the example, we can see vendor extension entry(0xE0) do not have > > associated cluster allocations. > > From "8.2 in the exFAT spec" as below, it is needed to handle all unrecognized > benign secondary entries that include NOT specified in Revision 1.00. > > 8.2 Implications of Unrecognized Directory Entries Future exFAT specifications > of the same major revision number, 1, and minor revision number higher than > 0, may define new benign primary, critical secondary, and benign secondary > directory entries. Only exFAT specifications of a higher major revision number > may define new critical primary directory entries. Implementations of this > specification, exFAT Revision 1.00 File System Basic Specification, should be > able to mount and access any exFAT volume of major revision number 1 and > any minor revision number. This presents scenarios in which an > implementation may encounter directory entries which it does not recognize. > The following describe implications of these scenarios: > ... > 4. Implementations shall not modify unrecognized benign secondary > directory entries or their associated cluster allocations. > Implementations should ignore unrecognized benign secondary directory > entries. When deleting a directory entry set, implementations shall > free all cluster allocations, if any, associated with unrecognized > benign secondary directory entries. > My understanding are 1. If new benign directory entries are defined in the future, the minor version number will be incremented. - If FileSystemRevision is 1.0, Benign secondary is only Vendor Extension DirectoryEntry or Vendor Allocation DirectoryEntry. - If FileSystemRevision is higher than 1.0, another Benign secondary entries are defined. - So it seems we need to add a check for FileSystemRevision in exfat_read_boot_sector() - If FileSystemRevision is higher than 1.0, mount with read only, because we can not handle the version. 2. Not all Benign secondary have FirstCluster and DataLength Fields. - Vendor Extension DirectoryEntry has no FirstCluster and DataLength Fields, and there are no clusters to free when deleting it. Table 36 Vendor Extension DirectoryEntry Field Name Offset(byte) Size(byte) EntryType 0 1 GeneralSecondaryFlags 1 1 VendorGuid 2 16 VendorDefined 18 14 - Vendor Allocation DirectoryEntry has FirstCluster and DataLength Fields, the associated cluster should be freed when deleting it. Field Name Offset(byte) Size(byte) EntryType 0 1 GeneralSecondaryFlags 1 1 VendorGuid 2 16 VendorDefined 18 2 FirstCluster 20 4 DataLength 24 8 BTW, I start my Spring Festival vacation tomorrow, so I may not be able to respond to emails in time.
