Hi~ I have a question about FAT32

Hi, there~

I have searched a file formatted by FAT32 recently, some of questions
doesn't be cleared.

My file is generated by fdisk utility, like this

"dd bs=1M count=32 if=/dev/zero of=./backing_file

fdisk ./backing_file

and so on...."

You know what I did, of course, to test linux gadget driver making a
file as parameter of driver.

After all of this, I dumped the file, it showed awesome result.

00000000h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
......(all zero)
000001c0h: 01 00 0B 0F 48 FF 08 00 00 00 F8 FF 00 00 00 00
......(all zero)
000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA

Above all are root records, first 1 sector.
As I know, boot record keeps some of infomations about partition,
root directory etc
but my file doesn't have, except only one partition info, partition
information also
I can't understand.

This is my first questiion~

And Reserved area(32 sectors in FAT32, right?, as I know) are
located,

......h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
......(all zero)
000011f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
00001200h: F8 FF FF FF 00 00 00 00 FF FF FF FF FF FF 00 00
.......(all zero)
Next FAT1, FAT2 are located,
(If reserved area size is 32 sectors, FAT1's location 000065f0h
00009200h: F8 FF FF FF 00 00 00 00 FF FF FF FF FF FF 00 00
.......(all zero)
F8 FF FF FF 00 00 00 00 FF FF FF FF FF FF 00 00 <- what's this??
this line appears twice.

Because FAT1,2 have cluster chain info, it means cluster chain? I
don't know
This, second question~

.......(all zero)
Since it's ok Root directory to be placed in anywhere, I find it

00011200h: E5 32 00 32 00 32 00 2E 00 74 0 0F 00 32 78 00
00011210h: 74 00 00 00 FF FF FF FF FF FF 00 00 FF FF FF FF
00011220h: E5 32 32 20 20 20 20 20 54 58 54 20 00 64 00 00
00011230h: 21 00 21 00 00 00 00 00 21 00 03 00 04 00 00 00
00011240h: 41 33 00 33 00 33 00 2E 00 74 00 0F 00 56 78 00
00011250h: 74 00 00 00 FF FF FF FF FF FF 00 00 FF FF FF FF
00011260h: 33 33 33 20 20 20 20 20 54 58 54 20 00 64 00 00
00011270h: 21 00 21 00 00 00 00 00 21 00 04 00 04 00 00 00
......(all zero)


I am interested in where real data cluster is and how to find it.
For example, 333.txt (00011260h)'s real data location is 00 04(by
FAT32 format)
, 4th cluster, it means that data cluster is from FAT2's last? or
file's first?
my last question~


please help me^^

thanks in advance~

sh1025.oh@samsung.com wrote:
> Hi, there~
>
> I have searched a file formatted by FAT32 recently, some of questions
> doesn't be cleared.
>
> My file is generated by fdisk utility, like this
>
> "dd bs=1M count=32 if=/dev/zero of=./backing_file
>
> fdisk ./backing_file
>
> and so on...."
>
> You know what I did, of course, to test linux gadget driver making a
> file as parameter of driver.
>
> After all of this, I dumped the file, it showed awesome result.
>
> 00000000h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ......(all zero)
> 000001c0h: 01 00 0B 0F 48 FF 08 00 00 00 F8 FF 00 00 00 00
> ......(all zero)
> 000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
>
> Above all are root records, first 1 sector.
> As I know, boot record keeps some of infomations about partition,
> root directory etc
> but my file doesn't have, except only one partition info, partition
> information also
> I can't understand.
>
> This is my first questiion~
>
> And Reserved area(32 sectors in FAT32, right?, as I know) are
> located,
>
> .....h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> .....(all zero)
> 000011f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
> 00001200h: F8 FF FF FF 00 00 00 00 FF FF FF FF FF FF 00 00
> ......(all zero)
> Next FAT1, FAT2 are located,
> (If reserved area size is 32 sectors, FAT1's location 000065f0h
> 00009200h: F8 FF FF FF 00 00 00 00 FF FF FF FF FF FF 00 00
> ......(all zero)
> F8 FF FF FF 00 00 00 00 FF FF FF FF FF FF 00 00 <- what's this??
> this line appears twice.
>
> Because FAT1,2 have cluster chain info, it means cluster chain? I
> don't know
> This, second question~
>
> ......(all zero)
> Since it's ok Root directory to be placed in anywhere, I find it
>
> 00011200h: E5 32 00 32 00 32 00 2E 00 74 0 0F 00 32 78 00
> 00011210h: 74 00 00 00 FF FF FF FF FF FF 00 00 FF FF FF FF
> 00011220h: E5 32 32 20 20 20 20 20 54 58 54 20 00 64 00 00
> 00011230h: 21 00 21 00 00 00 00 00 21 00 03 00 04 00 00 00
> 00011240h: 41 33 00 33 00 33 00 2E 00 74 00 0F 00 56 78 00
> 00011250h: 74 00 00 00 FF FF FF FF FF FF 00 00 FF FF FF FF
> 00011260h: 33 33 33 20 20 20 20 20 54 58 54 20 00 64 00 00
> 00011270h: 21 00 21 00 00 00 00 00 21 00 04 00 04 00 00 00
> .....(all zero)
>
>
> I am interested in where real data cluster is and how to find it.
> For example, 333.txt (00011260h)'s real data location is 00 04(by
> FAT32 format)
> , 4th cluster, it means that data cluster is from FAT2's last? or
> file's first?
> my last question~
>
>
> please help me^^

I dobt many her can.

This s deep stuff seldom explored by casual linux users

You should google FAT32 disk layout or similar. Somwhere the
specifications will be online.

>
> thanks in advance~
>

> "dd bs=1M count=32 if=/dev/zero of=./backing_file
>
> fdisk ./backing_file

Okay I'm not quite sure why you're doing fdisk on a file. Unless you
intend to dd the entire file onto the entire device instead of the
partition. And why only 32MB? It's not likely that you have any devices
(outside of fairly ancient CF, SD, Smart32 storage cards in this day and
age. Even windows can format up to 32GB of Fat32 type partitions.
Unless you're talking about a Fat16 (2GB limit) or Fat12 (1.44MB
floppies) filesystem.

Fdisk is going to put an MBR and partition tables allocation on the
file. As I wonder if that is 512 bytes of info or 1K. And also wonder
how you tell mkdosfs to use a partition of said file instead of the
entire file. There's probably ways around it by using split to segment
it, then mkdosfs, then cat file1 file2 > joined file. But that seems
unnecessarily complex.

If you don't exclude the partition table and mbr allocation from the
mkdosfs step, your first 512 or so bytes won't have the original 00's you
allocated it with. Which might be where you're getting confused from.
Although the post step of mkdosfs should make a usable filesystem
regardless. It'll just be harder to reverse engineer with the extra
data. By why reverse engineer it, you should have the source code that
does the task. Not that that's any less cryptic. But probably more
accurate and detailed.

But I'm making assumptions since you didn't explicitly state all of the
steps your took. Or what exactly you're trying to do. How does a file
have sectors? or heads? or cylinders? Although one must note that a
1.44MB floppy really holds 1.7MB-ish of data. It's just that once you
account for the Fat12 overhead, you're left with 1.44MB of useable
space. And modern 80GB devices are based of a 1,000 byte K, not 1024
bytes. So they're not really 80GB devices from certain (the computer/OS)
perspectives.

HTH

On Wed, 05 Sep 2007 12:34:35 -0000, Shadow_7
<wwwShadow7@yaNOhoo.comNULL> wrote:
>
>
> But I'm making assumptions since you didn't explicitly state all of the
> steps your took. Or what exactly you're trying to do. How does a file
> have sectors? or heads? or cylinders? Although one must note that a
> 1.44MB floppy really holds 1.7MB-ish of data.

Only when it is custom-formatted, as in the Tom's root boot floppy. A
standard 1.44MB floppy has 80 cylinders, 2 heads, 18 sectors per track.
tomsrtbt uses 82 cylinders, 21 sectors per track. USB floppy drives
can't read or format disks that way.


--
Since aerosols are forbidden, the police are using roll-on Mace!

sh1025.oh@samsung.com schrieb:

> After all of this, I dumped the file, it showed awesome result.
>
> 00000000h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ......(all zero)
> 000001c0h: 01 00 0B 0F 48 FF 08 00 00 00 F8 FF 00 00 00 00
> ......(all zero)
> 000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
>
> Above all are root records, first 1 sector.
> As I know, boot record keeps some of infomations about partition,
> root directory etc
> but my file doesn't have, except only one partition info, partition
> information also
> I can't understand.
>
You didn't inform fdisk about the "geometry" of your file, did you?
Something like

$ /sbin/fdisk -b512 -C10 -H255 -S63 ./backing_file

When I do that, I get

000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
0001c0 01 00 83 fe 3f 09 3f 00 00 00 4b 73 02 00 00 00
0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*

which is more like a usual LBA partition table.

For your questions about FAT32 internals, you should better ask one of the
developers which fiddled with it (or find and read some decent
documentation on it).

Kind regards

Jan

On Wed, 05 Sep 2007, sh1025.oh wrote:

> My file is generated by fdisk utility, like this
>
> "dd bs=1M count=32 if=/dev/zero of=./backing_file
>
> fdisk ./backing_file

What's this supposed to achieve?

> You know what I did, of course, to test linux gadget driver making a
> file as parameter of driver.

I don't understand this at all.


--
Yves Bellefeuille
<yan@storm.ca>