FullFAT, a fully featured FAT 12/16/32 library

[patchworks]

ReactOS devs apreciated it mutch, so I hope it can help here too:

• Fast and Efficient with Low Memory Footprint
  
• Scalable from Embedded Systems to Desktop OS’s
  
• Thread Safe
  
• Multiple File Open
  
• LFN Support (optional).
  
• Fully Featured
  
• Optional Caching
  
• Safe Caching behaviour
  
• Customisable Caching behaviour
  
• Multiple & Single Block Reading
  
• Platform independent, no assumptions about Endianess
  
• Easily integrated into current OS’s and Frameworks
  

I have begun writing this library because I am dissatisfied with the many Free FAT implementations, the ones that implement LFN’s are bloated and slow, like the FreeDOS driver. Others are lacking in features, buggy, or no longer actively developed.

The aim is make a really high-quality FAT driver that is flexible for many different needs, and do it better than any commercially available option.

http://code.google.com/p/fullfat/

Edited August 22, 2009 by patchworks

[patchworks]

UPDATE:

FullFAT 0.98 (Release Candidate 3) Download Now Available

This is a pre-1.0 release, and includes a snapshot of the current SVN also including the FFTerm project for the Visual Studio Demo. This is a more refined BETA than the previous, and has the following new features:

• Path Cache (info in ff_config.h).
  
• Date and Time support.
  
• Append File Mode support.
  
• FF_Open() now uses simple mode flags.
  
• FF_GetModeBits() function converts fopen() style mode strings to the appropriate flags.
  
• Public API now has consistent ERROR types. (FF_ERROR) = (FF_T_SINT32).
  
• Much improved demo with MD5 check, wildcard copying, remove command.
  
• Demo now includes an imaging command, disk image files to be quickly made.
  
• Demo now includes a multi-threaded file I/O testing facility.
  

I'm now testing FullFAT thoroughly, if anyone can help please get in touch (www.worm.me.uk/contact/). I'm also spending time writing comprehensive documentation, although this may take a couple of weeks. So I estimate an official 1.0 release for end of July.

[patchworks]

FullFAT 1.0.0 (RTM) Released

FullFAT 1.0.0 has now gone through a large amount of testing, and is now considered stable.

A new 1.0.0 (FINAL) release will be available in the coming weeks. This will contain the same source code (unless any major bugs are found) however will contain extra drivers, updated demo's for linux, etc etc. As well as a complete stdio integration demo.

New features:

* FF_Move() (rename) API added.

* Deleting now removes LFNs.

* Some minor bug-fixes and code cleanups.

Note:

Please format any media that was used with earlier versions of FullFAT. Earlier versions didn't delete LFN entries, and therefore left orphan LFN entries. This when renaming a file with 1.0.0 this can appear as a bug. However 1.0.0 is not broken, its just that the directory is corrupt from earlier versions.

[jaclaz]

I don't know.

What would be the use of a FAT12/16/32 library on systems that already support those filesystems natively?

jaclaz

[Chozo4]

I don't know.

What would be the use of a FAT12/16/32 library on systems that already support those filesystems natively?

jaclaz

There technically isn't any use. Patchworks is posting this stuff as a way to continue pushing the 'open source windows' idea of theirs since the past couple years if I'm correct. Which if I recall was saying to replace everything (or as much as possible) in windows with open source equivalents/replacements.

[jaclaz]

There technically isn't any use.

I know.

It was a rhetorical question.

Patchworks is posting this stuff as a way to continue pushing the 'open source windows' idea of theirs since the past couple years if I'm correct. Which if I recall was saying to replace everything (or as much as possible) in windows with open source equivalents/replacements.

Well, though I do not agree with the "pushing" idea, and with the way it is done, I personally find that the "plot" is not wrong in itself, only I find that it would be nice to have Open Source alternatives for Windows 9x/Me components that give you more features, while I find useless alternatives with SAME features.

As an example, if that library (or more accurately IFS drivers deriving from it) would allow access to NTFS and exFAT64, it would be useful and could replace the "standard" MS ones ALSO for the functions that we already have.

And however, having a library, while being a good thing, is far from having an actual working driver.

jaclaz

[dencorso]

<snip>

And however, having a library, while being a good thing, is far from having an actual working driver.

Very true. And, since our most capable developers have their hands full already, for the present and into the foreseeable future, and since we're not exactly an exponentially growing community, I dare say no amount of pushing, and no amount of shoving also, BTW, will be capable of preventing this ideia from being on idefinite hold for the present, the near future and even maybe the far future. While more ideas are always welcome, more developers willing to work on 9x/ME are much more welcome, but I sincerely fail to see an enormous horde of developers in the horizon, brawling furiosly in order to ascertain who'll be the first to start new projects in 9x/ME...