Search the Community

Being sufficiently ancient to recall CP/M, monochrome CRTs, and woolly mammoths, I thought I'd share something from the bad old days: FAT filesystems (FAT12, FAT16, FAT32). Still widely used in USB flashRAM, SD cards, RAMdisks, and microcontroller-based embedded systems, (F)ile (A)llocation (T)able filesystems are simple and robust, providing a great environment for learning how filesystems work. Moreover, many operating systems other than Windows can handle them, enabling data exchange between different platforms. That's the good part. I've often wondered why nobody had yet written a FAT UDF library for AutoIt. Now I know why. When a normally bone-dry tech page introduces FAT with the words "Welcome to Hell" you know you're in for a rough ride. It took me almost a year of grief and many, many wrecked (virtual) volumes to get to this first beta release. That's the bad part. Why was it so painful to develop, you rhetorically ask? The I/O itself is fairly straightforward, but backward compatibility, poor design choices and some blatant mistakes have produced a convoluted mess of rules with exceptions, exceptions to the exceptions, and exceptions to the exceptions to the exceptions (and in case you're wondering, no, I'm not talking about my own scripts here). It's like the Gregorian calendar, which has 365 days per year, unless the year is divisible by 4 (366), unless the year is also divisible by 100 (365), unless the year is also divisible by 400 (366). Add to that non-standard address-widths (paired 12-bit in FAT12, 28-bit in FAT32), file fragmentation, lost clusters, cross-, open-, and self-linked chaining errors, and the train wreck that is VFAT Long File Names support , and you've got yourself a challenge. The result is a main library called the FAT Suite (FATsuite.au3), to which I've added a large demo GUI called FAT Manager (FATman.au3, not to be confused with the famous superhero), plus my trusty MBR handler (BuildPartitionTable.au3), and a few sample image files with different types of FAT. If running older versions of AutoIt, you'll additionally need Yashied's outstanding WinAPIEx.au3. I've also gratefully incorporated two excellent UDFs by Ascend4nt and trancexx respectively (with acknowledgement, of course). Many thanks to you all! When you start FATman and load a volume, you'll see a pretty lame directory/file tree above a small log-window (ripped from my CodeScanner). Bog-standard menus allow you to copy, rename, remove files and dirs, etcetera. No big deal, right? You're not impressed. But please consider this: When FATman loads a volume (either from an image file or a physical drive) it is unmounted. As far as Windows is concerned, the volume is inaccessible to you. But your actions are not handled by the OS, but by the FATsuite UDFs. If you don't appreciate the significance of unmounted full access, then this library probably isn't for you. For my fellow codehounds, however, check out the main features below. And yes, it can be slow for large filled volumes with a small cluster size (especially the demo GUI tree refresh). But it also offers you full access to your files and other data, that is, more than Windows usually offers you. Main Features: FAT volume creation and (re)formatting (18 KB - 2 TB; slow for large volumes) visualising FAT architecture, with interactive tool (manipulate total size, cluster size, number of FAT copies) two-way file transfer between FAT volume and memory (UDF only, no GUI support) two-way file transfer between FAT volume and other, mounted (FAT/NTFS) volumes internal volume-, directory-, and file I/O (create/copy/move/truncate/remove/rename/filefind/edit filespecs) *physical* directory sorting by any criterion (unlike MicroSoft's "sorted" view of physically unsorted data) wiping files and physical removal of "deleted" files/subdirs in dir table and zeroing DataRegion clusters retrieving lost/deleted/damaged data clusters (with or without FAT reference) detecting/patching FAT chaining errors (cross-linked, open-ended, and circular chains) raw FAT I/O, including flipping CleanShutdown and Hard R/W-error bits manipulating bad clusters (single creation/single removal/bulk removal) with file chain rerouting determining cluster ownership for any defined FAT entry extracting all filesystem parameters, and editing some rawcopy image-to-volume and volume-to-image (imagefile or physical device) optional comparison/synchronisation of multiple FAT copies (the table, not the entire volume) File Find utility (UDF only, no GUI support) heavily annotated code for learning about FAT filesystem mechanics But beware, you can do enormous damage to your FAT volumes. For example, there's no soft-delete with recycle bin retrieval, and confirmation checks are few. Once you remove/wipe/truncate a file, it's gone forever, period. So please, please, please, read the FATsuite Remarks section before calling its UDFs; also read the annotations in the UDFs; study FATman's many examples; always work with imagefiles of which you keep multiple backup copies. Remember, it's a beta release ( glitches possible!); you may accidentally parse a wrong parameter at some point; and Murphy's Law always applies. FATsuite.v1.1.7z (AutoIt 3.3.12 compliant version 1.1; likely won't run in legacy AutoIt environments) FATimageExamples.7z Sample FAT image files (reduced in size) I hope this contribution helps to clarify how FAT filesystems work, and that you have fun playing with it, or find some other use(s) for it. RT PS Okay, I admit the mammoth was already slightly dead when I saw it, and had been for quite a while.