EmbeddedRelated.com
Forums

Free FAT12/FAT16/FAT32 filesystem (C)

Started by larwe January 9, 2006
Jonathan Kirwan wrote:

> 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.
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: http://sourceforge.net/project/delorie.htm (not found) Attempted URL: http://sourceforge.net/delorie.htm (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.
On 9 Jan 2006 15:53:04 -0800, "larwe" <zwsdotcom@gmail.com> wrote:

>Jonathan Kirwan wrote: > >> 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. > >FOILED!
It didn't work?? Well, that's news to me. I should have your set up, Lewin, so I could see for myself.
>------------------------- >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.
I didn't even know I had delorie.htm on my "web server" (which I don't even have any of.)
>Attempted URL: http://sourceforge.net/project/delorie.htm (not found) > >Attempted URL: http://sourceforge.net/delorie.htm (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.
Very odd. I exactly tried out that site (the one called http://sourceforge.net/projects/efsl 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
Jonathan Kirwan wrote:

> Very odd. I exactly tried out that site (the one called > http://sourceforge.net/projects/efsl > and I didn't develop it, you can be assured) without problems. So it > appeared, anyway.
Oh, the initial URL appears. You can't use any of the links, though.
On 9 Jan 2006 19:03:46 -0800, "larwe" <zwsdotcom@gmail.com> wrote:

>Jonathan Kirwan wrote: > >> Very odd. I exactly tried out that site (the one called >> http://sourceforge.net/projects/efsl >> and I didn't develop it, you can be assured) without problems. So it >> appeared, anyway. > >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
On 9 Jan 2006 19:03:46 -0800, "larwe" <zwsdotcom@gmail.com> wrote:

>Oh, the initial URL appears. You can't use any of the links, though.
By the way, the "About" on that sourceforge site says: "Library for filesystems intended to be used in embedded projects. The library currently supports FAT12/16/32 reading & writing on SD-cards, and is easily expandable for use with other devices on any platform." It's in C. Just so you know. Jon
On Tue, 10 Jan 2006 03:21:18 GMT, Jonathan Kirwan
<jkirwan@easystreet.com> wrote:

> So maybe I'll use this as >incentive to try and re-establish Lynx.
I found a Win32, version 2.8.5rel1 of Lynx at: http://keihanna.dl.sourceforge.jp/lynx-win32-pata/17942/Lynx285rel1THg.exe 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
On Mon, 9 Jan 2006 17:57:33 +0100, "Sagaert Johan" <sagaert.j  AT
belgacom.net> wrote:

>have a look here > >http://sourceforge.net/projects/efsl
Docs for it can be had at: http://puzzle.dl.sourceforge.net/sourceforge/efsl/manual-0.2.5.pdf or http://internap.dl.sourceforge.net/sourceforge/efsl/manual-0.2.5.pdf I note that it says that a minimum of 1k RAM is required. Better performance with more. Jon
On Tue, 10 Jan 2006 03:35:46 GMT, Jonathan Kirwan
<jkirwan@easystreet.com> wrote:

>On 9 Jan 2006 19:03:46 -0800, "larwe" <zwsdotcom@gmail.com> wrote: > >>Oh, the initial URL appears. You can't use any of the links, though. > >By the way, the "About" on that sourceforge site says: > >"Library for filesystems intended to be used in embedded projects. The >library currently supports FAT12/16/32 reading & writing on SD-cards, >and is easily expandable for use with other devices on any platform." > >It's in C. Just so you know. >
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
larwe wrote:
> 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. >
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) << 8 | @@ -529,7 +529,7 @@ uint32_t DFS_OpenDir(PVOLINFO volinfo, u if (DFS_ReadSector(volinfo->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 <sys/types.h> +#include <stdint.h> //=================================================================== // Configurable items
Hi Steve,

> 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.
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.