2023-07-17 13:43 GMT+09:00, Yuezhang.Mo@xxxxxxxx <Yuezhang.Mo@xxxxxxxx>: > >> From: Namjae Jeon <linkinjeon@xxxxxxxxxx> >> Sent: Thursday, July 13, 2023 9:03 PM >> exfat_extract_uni_name copies characters from a given file name entry >> into >> the 'uniname' variable. This variable is actually defined on the stack of >> the >> exfat_readdir() function. According to the definition of the >> 'exfat_uni_name' >> type, the file name should be limited 255 characters (+ null teminator >> space), >> but the exfat_get_uniname_from_ext_entry() >> function can write more characters because there is no check if filename >> entries exceeds max filename length. This patch add the check not to copy >> filename characters when exceeding max filename length. > > This case is not compliant with the exFAT file system specification, I think > it is > better to return an error and let the user fix it with fsck. > The current fix may result in multiple files with the same name in a > directory. > > Such as, there are files $(filename255) and files $(filename255)1, > $(filename255)2... > in a directory, but they will all be found as $(filename255). We were considering between handling it as an error and like this patch. In windows, such files is visible and can be accessed without any error like this patch. And please don't assume that fsck can be run in all cases. In some products and scenarios, fsck cannot be executed and should not be expected. I can add an error print to make the user run fsck. > > >
