> > > > > >> + 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://dokumen.pub/sd- > 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.
