FAT16 help needed!!!

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
My code is writting data to a CompactFlash card.  I can see the data
with WinHex. But, windows does not acknowledge the file.  I'm using
the same functions as examples that work elsewhere in the project.  I
need help analyzing the FAT info to see where the problem is so I know
where the problem lies in the code.  I have read the FAT specs and
compared my file to good files and the differences are just not
evident.  Any help on this would be most appreciated.  I'm really
under the gun here.


Sean W.

Re: FAT16 help needed!!!

Quoted text here. Click to load it

If you create an empty FAT volume on your
system and mount it on a win box, doe it
appear?  If not, make an empty FAT volume
on the win box and compare it with yours
bit-by-bit.  Also run chkdisk/scandisk
on it and windows might be able to tell
you what's wrong.

Once you get an empty FAT volume to mount
with no errors, write a trivial file.
Again, if it won't mount or show, write
the same trivial file on the win box
and compare the 2 volumes.  If it seems
to work, be sure to run chkdisk/scandisk
to make sure.



Re: FAT16 help needed!!!
Quoted text here. Click to load it

Ask these questions, in this order:

Is there a partition table on the disk, or did you use a "big floppy"
format?
You should have an MBR on the card, i.e. it should be a "hard disk"
format card, not a "big floppy".

Does Windows mount the volume successfully?
No-> Check the MBR contents. If OK, check the LBR contents. Run
Scandisk on the volume and in particular look at what volume size is
reported.

Yes-> Start at the directory entry.

Is the file in the root directory? If not, you're running before you
can walk. Create an empty entry in the root directory.

I also suggest using an old version of Norton Disk Editor for DOS to
inspect your card. It has an inbuilt FAT filesystem implementation and
it's most useful for browsing sectors in a "cooked" mode, interpreting
raw data as FAT, directory entries, LBR, MBR, ...

Re: FAT16 help needed!!!
Quoted text here. Click to load it

It works either way. In fact, Windows, when formatting a CF card does
not write an MBR but starts with the partition directly (i.e. the big
floppy aproach is used).

Markus

Re: FAT16 help needed!!!
Quoted text here. Click to load it

It may work either way under some circumstances, but _all_ embedded
equipment uses the hard disk type format for removable media. Why
behave strangely when there is a known standard to follow?

Re: FAT16 help needed!!!
Quoted text here. Click to load it

I respectfully disagre.

I just checked. My digital camera (a cannon PowerShot S45) which I'd
say should run under the term "embedded equipment" definately formats
the media the "big floppy" way. It accepts both formats which is wise
cause both formats IMHO seem to be widespread used. Then, considereing
that Windows formats CF's the big floopy way I really think that it's
not a good idea to exclusively support MBR based media in an embedded
system cause the likelyhood that an end user formats a CF in a Windows
system is quite big. To make things even worse, XP defaults to format
CompactFlash cards with FAT32 ! That's the main reason why I also
support FAT32 in my FAT implementation (which btw. supports
partitioning/formatting both kind of media). This implementation does
not support long filenames but ignores them if present.

Markus

Re: FAT16 help needed!!!
Quoted text here. Click to load it

How did you determine this, btw? It is not uncommon for Windows hosts
to show you only the int 24/25h "personality" of an inserted card,
i.e. no int 13h support - which means you can never see the MBR.
Example of drivers that work this way: Microtech DPCM-USB multi-card
reader/writer, but I'm aware of several others that have the same
behavior (just don't have their names to hand).

In testing literally hundreds of digital cameras for interoperability,
we never encountered one single camera that uses "big floppy" format.

Quoted text here. Click to load it

No! If I format a card on my Windows systems, if it already has an MBR
Windows will leave the MBR there. That is with either a PCMCIA adapter
or a USB adapter. If I destroy a card - zero it out - and then use
Windows to format it, the behavior depends on what I'm using to
connect the card to the Windows PC (and also the Windows version):

* PCMCIA card - Needs to be partitioned with FDISK and then formatted.
Haven't attempted this under NT-class Windows.

* USB reader with its own format utility - Right-clicking the volume
in My Computer and selecting Format invokes the OEM's format utility.
An MBR is automatically created.

* USB reader without a format utility, using generic storage class
driver - It winds up as a USB-floppy type volume.

Various other points come to mind, also, e.g. - will not work on
systems using True-IDE boot mode. Your point about be liberal with
what you accept and constrained with what you generate is well taken,
but in this case the conservative approach is _always_ to write
MBR-style cards.

Further, some formats (e.g. SSFDC) have hard-encoded in the format
specification a requirement to precede the filesystem with an MBR.
Truly, it is much safer to work with "hard disk" format.

Re: FAT16 help needed!!!
Quoted text here. Click to load it

No wonder. You were right, I'm wrong! I was fooled by my dump
utility/usb card reader which did not showed me the MBR!!!

Quoted text here. Click to load it

I this time took the ocasion to througly test, this time using my own
embeded hardware where I have full control about which sectors are
read etc. (as oposed to the USB card reader in my PC) and it turns out
that you are 100% right with all you said. The only thing you did not
mentioned is that windows XP defaults to formatting FAT32 on Cf cards.
That's probably important to know.

I can't remember anymore why I was asuming that many CF's would not
have an MBR. Basically I first implemented my FATxx software with only
MBR in mind and then stumbled across a card that did not had this and
as a result implemented my FAT library to also accept "big floppy"
kind of media (along with FAT12).  Maybe this is what triggered me
here. Well, I'm sorry and thanks for pointing all this out so clearly!

Happy new year!

Markus


Re: FAT16 help needed!!!


Quoted text here. Click to load it

If you read the FAT spec (fatgen102.pdf,
"FAT: General Overview of On-Disk Format")
I think that you will find that Microsoft
decides to format using FAT12/16/32 based
on the capacity of the device. IIRC, by
default, anything larger than 512MB is
formatted as FAT32, less than 512MB and
greater than 4MB it is formatted as FAT16,
and less than 4MB it gets a FAT12.


--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: FAT16 help needed!!!
snipped-for-privacy@larwe.com (Lewin A.R.W. Edwards) wrote in message
Quoted text here. Click to load it

I assume this made-up "big floppy" and "hard disk" terminology serves
mainly to confuse everyone?

It's perfectly valid to have a fixed disc (media type 0xF8) with or
without a partition table,and not unusual at all to have a partition
table with just one of the four entries occupied - pointing to a fixed
disc FAT image anyway,which always seemed a bit pointless to me.

Conversely the other media type bytes (0xF9/FC/FD/FE/FF) for removable
media can't have partition tables.It's just that flash cards from
cameras etc are considered by Windows et al as a 'fixed disc' but
which just happens to be removable!
Sprow.

Re: FAT16 help needed!!!
Quoted text here. Click to load it

Not really.  The technical distinction is, of course, presence or
absence of an MBR on the medium.  Actual floppy disks (5.25", and
their not quite so floppy 3.5" offspring) never have an MBR, which is
why the no-MBR way of creating a file system on a medium gained the
nickname "big floppy".  No confusion to be found here.

OTOH, the format with a partition table and a single primary partition
being referred to as "hard disk" is indeed a bit of a misnomer.  It
had better be called the "partitioned" style of formatting a medium.

Quoted text here. Click to load it

Is it?  So how would the system know not to treat the bytes in the
relevant part of the boot code of a big-floppy medium as a partition
table?

Quoted text here. Click to load it

... but since each of those is inherently tied to a particular floppy
disk format / density /sidedness, they may not be available for use
with other formats that don't match any of the ancient floppy disk
formats.

Quoted text here. Click to load it

Windows indeed allows this superficially self-contradictory state of
affairs --- but some other systems, at least traditionally, didn't.
If memory serves, OS/2 was one system that strictly refused to treat
anything but "big-floppy" formatted media as removable.  At that same
time, Windows didn't recognize anything big-floppy at all, causing
never-ending friction between these two systems, e.g. for users of MO
drives.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: FAT16 help needed!!!
Quoted text here. Click to load it

Partition tables and boot code can be distinguished between with
cunning software,signature bytes,presence/absence of zeros in
important places,partition table offset pointing to valid BPB of
course,etc...

Of the last 3 camera cards I looked at in depth,2 were partition
table-less,1 did have a partition table with only one entry,all 3 then
had a single FAT volume with media type 0xF8 and all opened fine in
Win98.

Though I would expect to find partition tables on the majority of
flash cards it's not mandatory.

Quoted text here. Click to load it

Absolutely.Still waiting to get my hands on some 8" discs to try
out...
Sprow.

Re: FAT16 help needed!!!
Quoted text here. Click to load it

You assume wrong, Grasshopper. It's a reasonable qualitative way to
differentiate between the two format methods, and it was at one stage
the way DOS programmers talked about the two. I believe the first time
I read it in a formal document was an Iomega whitepaper.

Quoted text here. Click to load it

That's really irrelevant; the number of entries in the ptable is
neither here nor there. The point is, embedded devices generate and
look for a partition table (in the main). It's a better
interoperability decision to format the card with an MBR and a single
partition spanning the entire disk, than simply to commence with an
LBR at physical sector 0. Yes, either are validly formatted disks, but
there's a range of circumstances under which the latter won't work,
whereas the former is the "industry standard" for cases where there is
no actual formal standard.

And in some cases, flash media format specifications MANDATE that an
MBR be present; in which case, it is perfectly legal and expected that
if you put your MBR-less card in a compliant appliance, that appliance
will fall over and die.

Note that every consumer appliance with removable flash and a reformat
command in firmware that I have tested (which is a *large* number)
generates an MBR.

You can be practically certain that /dev/sda1 will mount (if sda is a
card-reader containing a card formatted in a piece of consumer
electronics).  You can be practically certain that /dev/sda won't.

Re: FAT16 help needed!!!

Quoted text here. Click to load it


What is the media type for 'big floppy' ??

( I never heard of it )


Re: FAT16 help needed!!!
Quoted text here. Click to load it

Don't know the media type, but some BIOSes need USB-memorysticks
configured as if it where a floppy, i.e. no MBR only an boot sector.

Maybe some of these sticks hide the MBR if they are not accessed by
the right driver ?!
---
42Bastian
Do not email to snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: FAT16 help needed!!!

Quoted text here. Click to load it

Other removable media, such as zip drives, also use an MBR even though
windows can only cope with a single partition on it (other OS's can use
more).






Re: FAT16 help needed!!!

Quoted text here. Click to load it

Other OS's don't have to use the MBR scheme of partitions either.
MBR is really only needed so that the BIOS can figure it out.

--
Darin Johnson
    Gravity is a harsh mistress -- The Tick

Re: FAT16 help needed!!!



Quoted text here. Click to load it

Dear Sean,

 during the past year I worked on a project of porting the FreeDOS'
 filesystem to an embedded architecture. The first thing I did was
 to compile the fs under MSVC, then I did many tests on a floppy,
 formatted FAT16 as a 128 kilobytes removeable media. I used a
 boot sector created by Windows, because I wanted the fs be able
 to read and write files just like Windows. Initially I  had the same
 problems you had:

 Windows was able to see the files but each time I tried to open them up,
 it turned out to be empty. After several hours spent using WinHex,
 I found that if I add an empty sector (512 bytes) between the last
 sector of the root directory and the first data sector, Windows
 was able to read correctly those files. It's still a mystery for me....


 I just downloaded fatgen102.pdf and I promised my self to read
 it carefully in order to see if what I did is correct or not.


 Enrico


Re: FAT16 help needed!!!

Quoted text here. Click to load it


Any chance you could GPL the version of embedded
Freedos that you created?



Re: FAT16 help needed!!!
Quoted text here. Click to load it

Not long after getting the uFlashTCP and ordering the 8 Meg M-Systems chip I
got FreeDOS to run on it, so it's a good selling point Jim. I thought
FreeDOS was already GPL'd though. But my configuration was done using the
M-Systems chip as I don't have write access to the 512K chip. If I did then
I imagine that the same technique would work for that. IIRC I just used the
files from the FreeDOS download. If you're interested, I can do a short
write-up on the few steps.

Dilton




Site Timeline