Free FAT12/FAT16/FAT32 filesystem (C)

Google Groups is being recalcitrant these past couple of days, so I
have no idea if the world will see this, but I've just released free C
source to my embedded FAT filesystem. I've tested this code on a
variety of platforms, including ARM, AVR and MSP430.

I know there are several such filesystems in the world, but this one
meets my particular requirements for functionality vs. footprint - it
may be useful for someone else too.

<http://www.zws.com/products/dosfs/>

This code should be considered beta; I would appreciate feedback as to
bugs.

Here's the abstract:

DOSFS is a FAT-compatible filesystem intended for fairly low-end
embedded applications. It is not the leanest possible implementation
(the leanest FAT implementations operate in << 512 bytes of RAM, with
heavy restrictions). This code strikes a good balance between size and
functionality, with an emphasis on RAM footprint.

Intended target systems would be in the ballpark of 1K RAM, 4K ROM or
more.

Features:

Supports FAT12, FAT16 and FAT32 volumes
Supports storage devices up to 2048Gbytes in size (LBA32)
Supports devices with or without MBRs (hard disks vs. floppy disks or
ZIP drives formatted as "big floppies")
Supports multiple partitions on disks with MBRs
Supports subdirectories
Can be operated with a single global 512-byte sector buffer
Fully reentrant code (assuming the underlying physical device driver is
reentrant and global sector buffers are not used). There are no global
variables in the filesystem
Does not perform any memory allocation
Partial support for random-access files

>Supports FAT12, FAT16 and FAT32 volumes
>Supports storage devices up to 2048Gbytes in size (LBA32)

Do you also support long filenames?

Markus

On Mon, 09 Jan 2006 11:44:03 +0100, Markus Zingg <m.zingg@nct.ch>
wrote:

>>Supports FAT12, FAT16 and FAT32 volumes
>>Supports storage devices up to 2048Gbytes in size (LBA32)
>
>Do you also support long filenames?

If you'd grabbed the README.TXT in the extremely small and easily
gzip'd and tar'd distribution, you'd have read:

      VFAT long filenames are not supported. There is a certain
      amount of patent controversy about them, but more importantly
      they don't really belong in the scope of a "minimalist embedded
      filesystem".

Somewhat limited (non-unicode) support, if my poor memory of the
16-bit FAT case is any guide, isn't that hard to add.

Jon

>If you'd grabbed the README.TXT in the extremely small and easily
>gzip'd and tar'd distribution, you'd have read:

I implemented FAT12/16/32 quite similarly ~3 years ago and also left
out long filename support for similar reasons. The library would have
rised my interest if it were to support long filenames because I
thought it would be tuff to implement this with the resources
specified and also because I wondered how he would get away with the
licensing issue. 

Btw, Microsoft made FAT32 (and particularlly long filename support)
available under a license. From what I understood the license is
afordable for small projects but still a license... The intention -
again as I understood it - are to: 

a) make money from the big guys (cameras, USB devices etc.pp sold in
masses)
b) guarantee that long filename support is implemented propperly by
leaving a door open for small/simple not mainstram business
applications of it.

Markus

Markus Zingg wrote:

> Btw, Microsoft made FAT32 (and particularlly long filename support)
> available under a license. From what I understood the license is
> afordable for small projects but still a license... The intention -

The patents on which that was based were invalidated by the USPTO.

larwe wrote:
> Markus Zingg wrote:
> 
> 
>>Btw, Microsoft made FAT32 (and particularlly long filename support)
>>available under a license. From what I understood the license is
>>afordable for small projects but still a license... The intention -
> 
> 
> The patents on which that was based were invalidated by the USPTO.
> 
Do you have a link about this ??

donald

Donald wrote:

> >>Btw, Microsoft made FAT32 (and particularlly long filename support)
> >>available under a license. From what I understood the license is
> >
> > The patents on which that was based were invalidated by the USPTO.
> >
> Do you have a link about this ??

The easiest reference - because I'm lazy - is a mere mention
<http://en.wikipedia.org/wiki/File_Allocation_Table>
search for "October 6, 2005"

In any case, the facts of the issue are: FAT32 per se contains nothing
patented. The patents pertain to having multiple databases of filenames
on the disk, i.e. LFNs in this case (which can be and are implemented
on FAT12 and FAT16 also). The patents in question were re-examined and
invalidated, so there is no longer anything to license. However
Microsoft's licensing page for FAT "patents" is still a live link and I
don't want to get involved in FUD and discussion.

Of course the above argument is really specious and the real reason I
don't implement LFNs is because I don't have any use for them in my
application, and I'm lazy ;) Okay, I admitted it.

I suspect the reason for the licensing program was more so that MS
would be able to exert leverage on embedded device manufacturers to
support MS formats or lose their "FAT license". The fee was $0.25 per
device shipped, up to a cap of $150K (lifetime) per manufacturer, which
is a peppercorn as far as MS is concerned.

have a look here

http://sourceforge.net/projects/efsl

"larwe" <zwsdotcom@gmail.com> wrote in message
news:1136779531.250972.315290@g47g2000cwa.googlegroups.com...
> Google Groups is being recalcitrant these past couple of days, so I
> have no idea if the world will see this, but I've just released free C
> source to my embedded FAT filesystem. I've tested this code on a
> variety of platforms, including ARM, AVR and MSP430.
>
> I know there are several such filesystems in the world, but this one
> meets my particular requirements for functionality vs. footprint - it
> may be useful for someone else too.
>
> <http://www.zws.com/products/dosfs/>
>
> This code should be considered beta; I would appreciate feedback as to
> bugs.
>
> Here's the abstract:
>
> DOSFS is a FAT-compatible filesystem intended for fairly low-end
> embedded applications. It is not the leanest possible implementation
> (the leanest FAT implementations operate in << 512 bytes of RAM, with
> heavy restrictions). This code strikes a good balance between size and
> functionality, with an emphasis on RAM footprint.
>
> Intended target systems would be in the ballpark of 1K RAM, 4K ROM or
> more.
>
> Features:
>
> Supports FAT12, FAT16 and FAT32 volumes
> Supports storage devices up to 2048Gbytes in size (LBA32)
> Supports devices with or without MBRs (hard disks vs. floppy disks or
> ZIP drives formatted as "big floppies")
> Supports multiple partitions on disks with MBRs
> Supports subdirectories
> Can be operated with a single global 512-byte sector buffer
> Fully reentrant code (assuming the underlying physical device driver is
> reentrant and global sector buffers are not used). There are no global
> variables in the filesystem
> Does not perform any memory allocation
> Partial support for random-access files
>

Sagaert Johan wrote:
> have a look here
>
> http://sourceforge.net/projects/efsl

Unfortunately it tries to load an advertisement from ad.doubleclick.net
(which is blocked by my anti-advertising software) and some Javascript
or something on the page sees that the advertisement could not load,
tries again, tries again, ... and locks the browser up hard.

I'm not spending time on a site that's so determined to show me
graphical spam.

There is no advertising on zws.com :)

On 9 Jan 2006 12:23:19 -0800, "larwe" <zwsdotcom@gmail.com> wrote:

>Sagaert Johan wrote:
>> have a look here
>>
>> http://sourceforge.net/projects/efsl
>
>Unfortunately it tries to load an advertisement from ad.doubleclick.net
>(which is blocked by my anti-advertising software) and some Javascript
>or something on the page sees that the advertisement could not load,
>tries again, tries again, ... and locks the browser up hard.
>
>I'm not spending time on a site that's so determined to show me
>graphical spam.

Try Delorie's web site for viewing web sites with Lynx;
  http://www.delorie.com/web/lynxview.html
and just type in the above address.  Pleasingly absent of ads.

Jon