Re: Free FAT12/FAT16/FAT32 filesystem (C)

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

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

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

Do you have a link about this ??

donald

The easiest reference - because I'm lazy - is a mere mention

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

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 :)

Try Delorie's web site for viewing web sites with Lynx;

and just type in the above address. Pleasingly absent of ads.

Jon

FOILED!

Not Permitted You need to create a file called delorie.htm on your web server to prove you're the webmaster. When I see this file (it can be empty) I'll allow my tools to access your site.

Attempted URL:

(not found)

Attempted URL:

(not found)

Because these tools act basically as proxies, it's important to make sure that the people using these tools are actually the developers of the pages they're viewing, and not just random visitors trying to bypass filters or hide their identities.

It didn't work?? Well, that's news to me. I should have your set up, Lewin, so I could see for myself.

I didn't even know I had delorie.htm on my "web server" (which I don't even have any of.)

Very odd. I exactly tried out that site (the one called

and I didn't develop it, you can be assured) without problems. So it appeared, anyway.

You've got a mighty picky situation.

Have you tried simply getting Lynx fired up on your system? (Delorie didn't develop Lynx and the source is freely available for compilation on Linux, I believe.)

Jon

Oh, the initial URL appears. You can't use any of the links, though.

AH!!!!! Thanks, Lewin. I didn't bother with that. Darn, that means I'd need to install Lynx on my machine. I think I'm going to go to the trouble to find a win98se usable version of Lynx for some of my browsing -- it's been years and years since I used Lynx, but there are times I still wish I had it laying around. So maybe I'll use this as incentive to try and re-establish Lynx. I think it will be easier for you, if you want to, as I suspect you are a heavy-linux user where I've not been for more than a decade (planning to set up for 386BSD, though, soon.)

Jon

It's in C. Just so you know.

Jon

I found a Win32, version 2.8.5rel1 of Lynx at:

It an installer for Win32 and you just run it and tolerate the crazy Japanese stuff as you proceed. Then, once installed, you've got one more problem -- it's configured for Japanese. So I went in, killed the existing LYNX.CFG file in the main directory and copied in the LYNX.CFG file that is in the org_docs subdir. Fixed.

Jon

Docs for it can be had at:

or

I note that it says that a minimum of 1k RAM is required. Better performance with more.

Jon

The license is LGPL though. AFAICR this means that a user of one's embedded system must have some way of replacing the LGPL'd library with a newer version of the same library. I think providing a linkable object file of everything without the library code is acceptable.

Regards Anton Erasmus

Hi looks very nice. I built it on Fedora Core 3. I found a couple of environment sensitivities, for instance uint8_t was not defined in the header file chain here. And I used some of the Linux tools to create a filesystem file which I can also mount on FC3. (I used mkdosfs). Anyway for some reason when the file is mounted as a loopback device, I can only create names in lower case. Your test program in main.c has strings in upper case. So I change your memcmp calls with strncasecmp.

I don't know if you care, but here is a patch file that should not break your build elsewhere, but will make it work out of the box on x86 FC3.

I am sure the google groups or newsgroups will mangle this patch, but it is very simple.

Thanks for your effort!

diff -uprN virgin/dosfs.c dosfs-1.0/dosfs.c

--- virgin/dosfs.c 2006-01-08 19:13:28.000000000 -0800

+++ dosfs-1.0/dosfs.c 2006-01-12 18:04:46.000000000 -0800 @@ -510,9 +510,9 @@ uint32_t DFS_OpenDir(PVOLINFO volinfo, u

do { result = DFS_GetNext(volinfo, dirinfo, &de);

- } while (!result && memcmp(de.name, tmpfn,

11));

• } while (!result && strncasecmp(de.name, tmpfn,

11));

- if (!memcmp(de.name, tmpfn, 11) && ((de.attr & ATTR_DIRECTORY) == ATTR_DIRECTORY)) {

• if (!strncasecmp(de.name, tmpfn, 11) && ((de.attr & ATTR_DIRECTORY) == ATTR_DIRECTORY)) { if (volinfo->filesystem == FAT32) { dirinfo->currentcluster = (uint32_t) de.startclus_l_l | ((uint32_t) de.startclus_l_h) unit, dirinfo->scratch, volinfo->dataarea + ((dirinfo->currentcluster - 2) * volinfo->secperclus), 1)) return DFS_ERRMISC; }

- else if (!memcmp(de.name, tmpfn, 11) && !(de.attr & ATTR_DIRECTORY))

• else if (!strncasecmp(de.name, tmpfn, 11) && !(de.attr & ATTR_DIRECTORY)) return DFS_NOTFOUND;

// seek to next item in list @@ -749,7 +749,7 @@ uint32_t DFS_OpenFile(PVOLINFO volinfo, return DFS_NOTFOUND;

while (!DFS_GetNext(volinfo, &di, &de)) {

- if (!memcmp(de.name, filename, 11)) {

• if (!strncasecmp(de.name, filename, 11)) { // You can't use this function call to open a directory. if (de.attr & ATTR_DIRECTORY) return DFS_NOTFOUND; diff -uprN virgin/dosfs.h dosfs-1.0/dosfs.h

--- virgin/dosfs.h 2006-01-08 19:13:31.000000000 -0800

+++ dosfs-1.0/dosfs.h 2006-01-12 16:35:57.000000000 -0800 @@ -7,6 +7,7 @@ #define _DOSFS_H

#include

+#include

//=================================================================== // Configurable items

Hi Steve,

Not sure what this will achieve. The directory entry should contain uppercase characters.

There is an oddity about the vfat driver in Linux, that it tries to prettify directory output by silently lowercasing 8.3 names when you list dir contents. IIRC if a filename you create COULD be represented as 8.3, it is stored on disk as the 8.3 uppercase version. Even if you specified lowercase when you created it, there will be no LFN entry containing this information. This fact is however semi-invisible under both Windows and Linux because of the magic translation in vfat and the case-agnosticism of Windows.

However, if you do this:

echo something > /mnt/vfat-device/OUTPUT.TXT cat /mnt/vfat-device/OUTPUT.TXT (no such file) cat /mnt/vfat-device/output.txt (shows output)

In other words, you can't trust the output of ls on Linux when looking at MSDOS volumes. The 8.3 alias for your filename will be stored in uppercase in the directory entry. It is a "kinda" spec violation to have lowercase letters in the 8.3 name (it will break many DOS programs). By "kinda" I mean that as far as I'm aware it isn't specifically disallowed, but under Microsoft OSs it is impossible to create such a directory entry without poking around with a sector editor.

I'll study your patch when I'm awake (I'm hallucinatingly tired at the moment) and see what else it addresses. Thanks for your feedback, much appreciated.

larwe schrieb:

Look at the chapter 'Mount options for vfat' in the MOUNT(8) manual page.

shortname=[lower|win95|winnt|mixed]

Defines the behaviour for creation and display of filenames which fit into 8.3 characters. If a long name for a file exists, it will always be preferred display. There are four modes: ...

Anton