From: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] fat: Handle moved FAT32 root directory
Date: Mon, 22 Oct 2012 01:25:30 +0200 (CEST) [thread overview]
Message-ID: <848164565.7298149.1350861930354.JavaMail.root@advansee.com> (raw)
In-Reply-To: <10395409.7297877.1350859974867.JavaMail.root@advansee.com>
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
parent reply other threads:[~2012-10-21 23:25 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <10395409.7297877.1350859974867.JavaMail.root@advansee.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=848164565.7298149.1350861930354.JavaMail.root@advansee.com \
--to=benoit.thebaudeau@advansee.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.