[U-Boot-Users] FW: USB SUPPORT & get_vfatname

[Adrian Filipi]

 	It looks like fat.c is not handling the case where the 
sectors/cluster is 1, and the rood directory spans multiple clusters.

 	In my case I was getting garbage directoy info after the invalid 
fat error.  The attached patch stops the code from rolling past the end of 
cluster.

 	It looks like a loop to walk the allocation chain is neccessary. 
I think get_contents() does all the right work, but it of course starts 
with a directory entry, which we don't have yet for /.  A little 
refactoring might do the trick.

 	Adrian
--
Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com

On Fri, 25 Apr 2008, michael wrote:

> Hi,
> Ken.Fuchs at bench.com wrote:
>> Michael Trimarchi wrote:
>>
>> 
>>> confirm that the problem is in fat.c file and I will try to fix.
>>> 
>> 
>> It has been confirmed that fatls does _not_ list
>> all files on FAT32 filesystems.
>> 
>> There are _no_ reports of fatls failing to list
>> all files on FAT16 filesystems.  (There may be
>> an unrelated bug caused by all 512 directory
>> entries of FAT16 being used.)
>> 
>> What additional information is needed to confirm
>> that the problem is in fat.c?
>>
>> 
> The problem is related to how fat.c manage the root directory. As reported by
> microsoft
> in "FAT32, the root directory can be of variable size and is a cluster chain, 
> just like any other directory is.
> The first cluster of the root directory on a FAT32 volume is stored in 
> BPB_RootClus. Unlike other directories,
> the root directory itself on any FAT type does not have any date or time 
> stamps, does not have a file name
> (other than the implied file name ?\?), and does not contain ?.? and ?..? 
> files as the first two directory entries in the directory.
> The only other special aspect of the root directory is that it is the only 
> directory on the FAT volume for
> which it is valid to have a file that has only the ATTR_VOLUME_ID attribute 
> bit set (see below)."
>> What is your response to the debug log you requested?
>> It was sent to the ml almost 18 hours ago and is
>> also quoted below.
>> 
> In my spare time a try to change the do_fat_read to support the chaining.
>
> Regards Michael
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fat.c.diff
Type: text/x-diff
Size: 1090 bytes
Desc: 
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080425/b9877796/attachment.diff