Namjae Jeon <linkinjeon@xxxxxxxxx> writes: >>> Hm, start with copy of fat_search_long() and refactoring it. With it, we >>> will be able to avoid the fixed bugs. >>> >>> After that, we might be able to merge those somehow. Well, I'm not >>> pretty sure without doing it actually though. > Hi OGAWA. > > When we checked to merge it with fat_search_long, we really did not > find any possibility of code reusing for fat_traverse_cluster. > It will not be proper. In case of fat_search_long()-> it is performing > a name based lookup in a particular directory. > While for reconnection with parent from NFS, we do not have the name > of the parent directory. We are relying on ‘i_pos’ on disk position of > directory entry. > So, on first request for lookup for “..” (i.e if we call > fat_search_long(child_dir->d_inode, MSDOS_DOTDOT,2,slot_info) it will > return the directory entry for “..” itself. From this entry we can > read the “log start” which is the starting cluster of the parent > directory, but instead we need the “directory entry” where this is > stored. > So, from this level we need to go further one level up and read the > parent ->parent-> cluster. After reading that cluster, we need to do a > lookup of the “required ipos” in this directory block. > i.e., if the path is A/B/C and we call the get_parent() from ‘C’. We > need to read the directory block contents of ‘A’ and from those > ‘directory entries' compare the log_start with the log_start value of > B, which was obtained by doing a lookup “..” in C. > So, Instead of it, we suggest we fix the “infinite-loop” condition in > fat_traverse_logic and retain the code. > of course, we will test it with corrupted FATfs. > Please share your thoughts on this. Yes, we can't use fat_search_long() as is, of course. However, we can share the basic algorithm and code. The both are doing, 1) traverse the blocks chained by ->i_start. 2) get the record (dirent) from blocks. 3) check the detail of record The difference is only (3), right? I know, the code has many differences though. The actual logic are almost same. And see, e.g., fat_get_cluster() is checking several unexpected state. We have to care about corrupting data. It is not only "infinite-loop" case. And why I'm saying it is better to share code. Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
