Dear Romain Izard,
On Thu, 09 Jun 2011 21:36:08 -0000, Romain Izard wrote:
The default location of the root directory in a FAT32 partition is the same as its location in a FAT12/16 partition. But a difference is that in FAT32, it is possible for the root directory to move.
This fix ensures that the parsing uses the root directory location stored in the PBR, instead of always using the default location.
Signed-off-by: Romain Izard romain.izard.pro@gmail.com
fs/fat/fat.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c index c450bf6..22d34d3 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -798,6 +798,8 @@ do_fat_read (const char *filename, void *buffer, unsigned long maxsize, if (mydata->fatsize == 32) { mydata->data_begin = mydata->rootdir_sect - (mydata->clust_size * 2);
cursect = mydata->data_begin +(root_cluster * mydata->clust_size);
Good find!
However, I don't think that hacking cursect is an appropriate fix. mydata->rootdir_sect should be fixed instead in the first place because: - it's cleaner, - mydata->rootdir_sect is used in a debug trace after that, - mydata->rootdir_sect is used by get_cluster(), and .. entries must give a 0 start cluster for the root directory, even on FAT32.
By the way, while reviewing the FAT code, I noticed that it must have the following bugs: - .. will be an issue in some way, especially if they reach the root folder on FAT12 or FAT16, - VFAT long file names will be broken if their entries cross the PREFETCH_BLOCKS barrier on FAT12/16, - do_fat_write() is also broken by the bug that you want to fix.
Also, do_fat_write() duplicates a lot of init code from do_fat_read_at(). A common function could be created from that to init a mydata (fsdata) structure from read_bootsectandvi().
So your patch could be changed to the following series: 1. Factorize do_fat_read_at() and do_fat_write() init (no change of behavior). 2. Fix this init by fixing mydata->rootdir_sect.
The other issues that I mentioned are unrelated to your patch and should be verified and addressed separately.
Best regards, Benoît