All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] fat: Handle moved FAT32 root directory
       [not found] <10395409.7297877.1350859974867.JavaMail.root@advansee.com>
@ 2012-10-21 23:25 ` Benoît Thébaudeau
  0 siblings, 0 replies; only message in thread
From: Benoît Thébaudeau @ 2012-10-21 23:25 UTC (permalink / raw)
  To: u-boot

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);
>  	} else {
>  		rootdir_size = ((bs.dir_entries[1]  * (int)256 +
>  				 bs.dir_entries[0]) *
> 

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2012-10-21 23:25 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <10395409.7297877.1350859974867.JavaMail.root@advansee.com>
2012-10-21 23:25 ` [U-Boot] fat: Handle moved FAT32 root directory Benoît Thébaudeau

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.