FAT16 fs mixed-case (as opposed to long) file name support

Greetings:

We need to migrate some FAT16 filesystems that use mixed case 8.3 names to a *nix or win32 platform; directory entries may also include win32 longnames in slots above the 8.3 name. All the flavors of DOS and win32 I've tried choke on the directories (suprisingly win2k 'chkdsk' reports no errors and the correct number of files and directories but the filesystem is unreadable).

I'd appreciate product or file system driver recommendations.

Michael Grigoni Cybertheque Museum

Reply to
msg
Loading thread data ...

It is illegal to have lowercase letters in the short directory entries. MS-DOS will not match File.Ext to FILE.EXT because it prefilters the

8.3 name.

If you just need to get the files off the card, you can use DOSFS's image emulation mode and tweak some of the string compares..

formatting link

Reply to
larwe

Hi Lewin and thanks!

I grabbed the code and built it with some tweaks on ANSI SCDE; just for funnies I tested it against a mixed-case 8.3 image and got:

Partition 0 start sector 0x00000011 active 00 type 04 size 0000806E Volume label 'jack '

8 sector/s per cluster, 1 reserved sector/s, volume total 32878 sectors. 17 sectors per FAT, first FAT at sector #18, root dir at #52. (For FAT32, the root dir is a CLUSTER number, FAT12/16 it is a SECTOR number) 1024 root dir entries, data area commences at sector #116. 4095 clusters (16773120 bytes) in data area, filesystem IDd as FAT16. error opening subdirectory

I will tweak the string compares...

BTW, I still use an eprom programmer I built in '98 based on your EPROMr PP design :-)

Michael Grigoni Cybertheque Museum

Reply to
msg

FWIW, I should mention the obnoxious way that DOS and Win32 filesystem implementations ignore the FAT16 (0x04) version byte in the MBR when the partition is shorter than 16MB; the ones I tested (versions of DRDOS/NWDOS, MS-DOS, Win95, Win98, NT/2k) treat such as FAT12 with varying unfortunate results.

Your DOSFS code gives me a head start to accomodate this situation off-line.

Regards,

Michael

Reply to
msg

The _defined behavior_ per Microsoft application notes is to gauge the FAT format by the size of the disk. It amazed me. I didn't know this until I wrote DOSFS.

Reply to
larwe

It's all part of the rigidly enforced Mickey$oft policy of debauching all standards. It you buy or use non-Mickey$oft software it is obviously your own fault.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: 
Also see
Reply to
CBFalconer

To be precise it's determined by the number of clusters in the volume (total sectors less the number of reserved sectors, FAT sectors and sectors for the root directory, all divided by the cluster size). Less than 4085 clusters, it's FAT12.

formatting link

Reply to
robertwessel2

I'm not sure you can really blame MS for that one. DOS 3.x (IIRC, FAT16 was introduced with DOS 3.0 and the AT) certainly used the MS documented method for determining the volume type (eg. looking at the number of clusters on the volume). So the "standard" (such as it is) is at least 20 years old.

Interesting note. I pulled an old MS reference off the bookshelf (The "MS-DOS Encyclopedia"), with a 1988 copyright. They document the cutover to FAT16 to be "...introduced with version 3.0....large fixed disks with more than 4087 clusters, use 16-bit links." The count is off by three (should be 4085 or more clusters for FAT16). So the method, if not quite the exact count, has been publicly documented for

18 years. Although it was certainly not as emphatically documented as one might have wanted that this is the only valid method.
Reply to
robertwessel2

Did you try the msdos/fat filesystems support in Linux mount? Or its mtools utilities?

Reply to
toby

That was the first thought that came to mind, however since the dostools we have on other Unix flavors confrom to MS specs I assumed that Linux verions would be no different. I would have to configure a new box to try them anyway...

Modifying the Linux msdos fs seems to me to be more of a 'project' than the tweaks I needed to make to Lewin's DOSFS code (am I wrong?)

I now have a working library which handles mixed- case names and FAT16 < 16MB. I will be adding lfn support as time permits.

I would still appreciate pointers to other products, open source or commercial which implement these features, either in the development environment or on the target (for future reference).

Regards,

Michael

Reply to
msg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.