Embeddable FAT filesystem

Can you recommend an embeddable FAT filesystem library that meet these
criteria:


Must Support:
1) FAT16, FAT32
2) Removable Media (CompactFlash)
3) Disk Format functionality
4) Check Disk functionality
5) Flush FAT capability


Should support:
1) FAT12, Long file name
2) SetFileSize capability
3) Thread-safety (through RTOS adaptation layer)
4) CompactFlash IO through common memory (rather than IO window)
5) Multiple sector writes
6) Write buffering


We are currently using a commercial, expensive, filesystem library, that is
an optional component of a very well known RTOS, but are extremely
disappointed with it. Removable media is not handle well at all (numerous
structures are not un-initialised on disk removal, which causes problems
when another disk is inserted), the format function is extremely unreliable
and can actually cause in invalid FAT, there is no API to verify that the
FAT is valid and the size of a file can not be set except by writing data
(to minimise chance of FAT corruption on sudden power loss or device
removal). Although we have the sources and have already fixed a dozen or so
bugs, it would be preferable to switch to a widely endorsed good quality
alternative.

Any recommendations for and/or against particular libraries would be greatly
appreciated.

Best regards


Tim Clacy

Tim Clacy wrote:
> Can you recommend an embeddable FAT filesystem library that meet these
> criteria:
> 
> 
> Must Support:
> 1) FAT16, FAT32
> 2) Removable Media (CompactFlash)
> 3) Disk Format functionality
> 4) Check Disk functionality
> 5) Flush FAT capability
> 
> 
> Should support:
> 1) FAT12, Long file name
> 2) SetFileSize capability
> 3) Thread-safety (through RTOS adaptation layer)
> 4) CompactFlash IO through common memory (rather than IO window)
> 5) Multiple sector writes
> 6) Write buffering
> 
> 
> We are currently using a commercial, expensive, filesystem library, that is
> an optional component of a very well known RTOS, but are extremely
> disappointed with it. Removable media is not handle well at all (numerous
> structures are not un-initialised on disk removal, which causes problems
> when another disk is inserted), the format function is extremely unreliable
> and can actually cause in invalid FAT, there is no API to verify that the
> FAT is valid and the size of a file can not be set except by writing data
> (to minimise chance of FAT corruption on sudden power loss or device
> removal). Although we have the sources and have already fixed a dozen or so
> bugs, it would be preferable to switch to a widely endorsed good quality
> alternative.
> 
> Any recommendations for and/or against particular libraries would be greatly
> appreciated.
> 
> Best regards
> 
> 
> Tim Clacy
> 
> 

What is the name/company name of the filessystem you are using?

I am currently using ERTFS(older version) from EBSnet inc and find it quite 
good. We are considering upgrading to a newer version.

Dave.

David Williams wrote:
> Tim Clacy wrote:
>> Can you recommend an embeddable FAT filesystem library that meet
>> these criteria:
>>
>>
>> Must Support:
>> 1) FAT16, FAT32
>> 2) Removable Media (CompactFlash)
>> 3) Disk Format functionality
>> 4) Check Disk functionality
>> 5) Flush FAT capability
>>
>>
>> Should support:
>> 1) FAT12, Long file name
>> 2) SetFileSize capability
>> 3) Thread-safety (through RTOS adaptation layer)
>> 4) CompactFlash IO through common memory (rather than IO window)
>> 5) Multiple sector writes
>> 6) Write buffering
>>
>>
>> We are currently using a commercial, expensive, filesystem library,
>> that is an optional component of a very well known RTOS, but are
>> extremely disappointed with it. Removable media is not handle well
>> at all (numerous structures are not un-initialised on disk removal,
>> which causes problems when another disk is inserted), the format
>> function is extremely unreliable and can actually cause in invalid
>> FAT, there is no API to verify that the FAT is valid and the size of
>> a file can not be set except by writing data (to minimise chance of
>> FAT corruption on sudden power loss or device removal). Although we
>> have the sources and have already fixed a dozen or so bugs, it would
>> be preferable to switch to a widely endorsed good quality
>> alternative.
>>
>> Any recommendations for and/or against particular libraries would be
>> greatly appreciated.
>>
>> Best regards
>>
>>
>> Tim Clacy
>>
>>
>
> What is the name/company name of the filessystem you are using?
>
> I am currently using ERTFS(older version) from EBSnet inc and find it
> quite good. We are considering upgrading to a newer version.
>
> Dave.

Dave,

Hi. ERTFS is one of the systems I am looking at as an alternative; how well
is removable media handled (e.g. removing a FAT16 disk and inserting a FAT32
disk)? Can you set/allocate file size before writing any data (e.g. using an
API like SetFilePointer or SetFileSize)? Can you flush the FAT out to disk
on demand?

I''l let you know, privately, the Vendor of the filesystem that we are
currently using, but if I were to publish that in this public newsgroup it
might incurr the wrath of libel lawyers (since I have absolutley nothing
good to say about that particular stinking pile of horse manure),

Regards


Tim

On Tue, 14 Sep 2004 09:28:15 +0200, "Tim Clacy"
<nospamtcl@nospamphaseone.nospamdk> wrote:

[snip]
>
>I''l let you know, privately, the Vendor of the filesystem that we are
>currently using, but if I were to publish that in this public newsgroup it
>might incurr the wrath of libel lawyers (since I have absolutley nothing
>good to say about that particular stinking pile of horse manure),
>

Mmm. Let's play to a variant of Woodward's game, then. I'll say a name. If you
don't answer in, say, 2 days, I'll asume it's the correct name. The name has to
do with air and water ;-)

--
Ignacio G.T.

"Tim Clacy" <nospamtcl@nospamphaseone.nospamdk> wrote in message news:<4145b871$0$222$edfadb0f@dread16.news.tele.dk>...
> Can you recommend an embeddable FAT filesystem library that meet these
> criteria:
> 
> 
> Must Support:
> 1) FAT16, FAT32
> 2) Removable Media (CompactFlash)
> 3) Disk Format functionality
> 4) Check Disk functionality
> 5) Flush FAT capability
> 
> 
> Should support:
> 1) FAT12, Long file name
> 2) SetFileSize capability
> 3) Thread-safety (through RTOS adaptation layer)
> 4) CompactFlash IO through common memory (rather than IO window)
> 5) Multiple sector writes
> 6) Write buffering
> 
> 
> We are currently using a commercial, expensive, filesystem library, that is
> an optional component of a very well known RTOS, but are extremely
> disappointed with it. Removable media is not handle well at all (numerous
> structures are not un-initialised on disk removal, which causes problems
> when another disk is inserted), the format function is extremely unreliable
> and can actually cause in invalid FAT, there is no API to verify that the
> FAT is valid and the size of a file can not be set except by writing data
> (to minimise chance of FAT corruption on sudden power loss or device
> removal). Although we have the sources and have already fixed a dozen or so
> bugs, it would be preferable to switch to a widely endorsed good quality
> alternative.
> 
> Any recommendations for and/or against particular libraries would be greatly
> appreciated.
> 
> Best regards
> 
> 
> Tim Clacy

It looks really bad.

I will give you some words, but you can ignore if they are not usefull
for you.

We tried to use a FAT file system, not as bad as you described, but
because the data that we save there is absolutely essensial to our
customers, and because, in our environment, the power can go alway any
time, we decide to move from fat to transacional file system, that it
is much more reliable than the other, so reliable that a check disk
utility is not necessary.
Before move from fat we looked at check disk utilities, I could find a
source code at freedos, but it is really big and can not fix all the
problems that can happen.
The same company that has the transactional file system has the flash
interface, that we use, to keep moving the new data in the flash to
new sectors, so the flash will not expire ealy.

> currently using, but if I were to publish that in this public newsgroup it
> might incurr the wrath of libel lawyers (since I have absolutley nothing

USFiles?

BTW, if you are describing problems you've encountered, there is no
possibility that a lawyer can hurt you unless you signed some specific
NDA that says you can't talk about anything to do with the product.

Jose Luis Marchetti wrote:
> "Tim Clacy" <nospamtcl@nospamphaseone.nospamdk> wrote in message
> news:<4145b871$0$222$edfadb0f@dread16.news.tele.dk>...
>> Can you recommend an embeddable FAT filesystem library that meet
>> these
>> criteria:
>>
>>
>> Must Support:
>> 1) FAT16, FAT32
>> 2) Removable Media (CompactFlash)
>> 3) Disk Format functionality
>> 4) Check Disk functionality
>> 5) Flush FAT capability
>>
>>
>> Should support:
>> 1) FAT12, Long file name
>> 2) SetFileSize capability
>> 3) Thread-safety (through RTOS adaptation layer)
>> 4) CompactFlash IO through common memory (rather than IO window)
>> 5) Multiple sector writes
>> 6) Write buffering
>>
>>
>> We are currently using a commercial, expensive, filesystem library,
>> that is
>> an optional component of a very well known RTOS, but are extremely
>> disappointed with it. Removable media is not handle well at all
>> (numerous
>> structures are not un-initialised on disk removal, which causes
>> problems
>> when another disk is inserted), the format function is extremely
>> unreliable
>> and can actually cause in invalid FAT, there is no API to verify
>> that the
>> FAT is valid and the size of a file can not be set except by writing
>> data (to minimise chance of FAT corruption on sudden power loss or
>> device
>> removal). Although we have the sources and have already fixed a
>> dozen or so
>> bugs, it would be preferable to switch to a widely endorsed good
>> quality
>> alternative.
>>
>> Any recommendations for and/or against particular libraries would be
>> greatly
>> appreciated.
>>
>> Best regards
>>
>>
>> Tim Clacy
>
> It looks really bad.
>
> I will give you some words, but you can ignore if they are not usefull
> for you.
>
> We tried to use a FAT file system, not as bad as you described, but
> because the data that we save there is absolutely essensial to our
> customers, and because, in our environment, the power can go alway any
> time, we decide to move from fat to transacional file system, that it
> is much more reliable than the other, so reliable that a check disk
> utility is not necessary.
> Before move from fat we looked at check disk utilities, I could find a
> source code at freedos, but it is really big and can not fix all the
> problems that can happen.
> The same company that has the transactional file system has the flash
> interface, that we use, to keep moving the new data in the flash to
> new sectors, so the flash will not expire ealy.

Jose,

Hi. We will be offering one or more transacted file system. However, FAT is
so widely supported it would be commercial suicide not support it. With a
good library, it should be possible to make even a FAT system pretty robust
(e.g. flushing FAT, seting file size).

Tim

Lewin A.R.W. Edwards wrote:
>> currently using, but if I were to publish that in this public
>> newsgroup it might incurr the wrath of libel lawyers (since I have
>> absolutley nothing
>
> USFiles?
>
> BTW, if you are describing problems you've encountered, there is no
> possibility that a lawyer can hurt you unless you signed some specific
> NDA that says you can't talk about anything to do with the product.

Lewin,

You know what these U.S. corporations can be like (oops, I should have said
it was a US corporation)

Ignacio G.T. wrote:
> On Tue, 14 Sep 2004 09:28:15 +0200, "Tim Clacy"
> <nospamtcl@nospamphaseone.nospamdk> wrote:
>
> [snip]
>>
>> I''l let you know, privately, the Vendor of the filesystem that we
>> are currently using, but if I were to publish that in this public
>> newsgroup it might incurr the wrath of libel lawyers (since I have
>> absolutley nothing
>> good to say about that particular stinking pile of horse manure),
>>
>
> Mmm. Let's play to a variant of Woodward's game, then. I'll say a
> name. If you don't answer in, say, 2 days, I'll asume it's the
> correct name. The name has to do with air and water ;-)

Hmm,  the name is not specific to any particular type of molecule...

Tim Clacy wrote:
> Can you recommend an embeddable FAT filesystem library that meet these
> criteria:
>
>
> Must Support:
> 1) FAT16, FAT32
> 2) Removable Media (CompactFlash)
> 3) Disk Format functionality
> 4) Check Disk functionality
> 5) Flush FAT capability
>
>
> Should support:
> 1) FAT12, Long file name
> 2) SetFileSize capability
> 3) Thread-safety (through RTOS adaptation layer)
> 4) CompactFlash IO through common memory (rather than IO window)
> 5) Multiple sector writes
> 6) Write buffering
>
>
> We are currently using a commercial, expensive, filesystem library,
> that is an optional component of a very well known RTOS, but are
> extremely disappointed with it. Removable media is not handle well at
> all (numerous structures are not un-initialised on disk removal,
> which causes problems when another disk is inserted), the format
> function is extremely unreliable and can actually cause in invalid
> FAT, there is no API to verify that the FAT is valid and the size of
> a file can not be set except by writing data (to minimise chance of
> FAT corruption on sudden power loss or device removal). Although we
> have the sources and have already fixed a dozen or so bugs, it would
> be preferable to switch to a widely endorsed good quality alternative.
>
> Any recommendations for and/or against particular libraries would be
> greatly appreciated.
>
> Best regards
>
>
> Tim Clacy

Check out uC/FS at www.micrium.com.  I believe it does all you want.

Scott