Clever Linux folk find way around Microsoft FAT file system patent

This site may earn affiliate commissions from the links on this page. Terms of use.

Score one for Linux developers. Andrew Tridgell, one of the lead developers on the Samba project, may have developed a workaround which will bypass a Microsoft patent on the ubiquitous FAT, VFAT and FAT32 file systems.

For those who don’t know, Linux comes with an Ext2, Ext3 or new Ext4 file system for its native use. This is a long-held requirement because some time ago, Microsoft developed the FAT, VFAT and FAT32 file systems (File Allocation Table, with 32-bit support for larger disks), which allows a disk to store its data. Note: This is a low-level aspect of the system (one not really seen by users), but it’s what physically holds the data that we see as filenames, dates, attributes and folders, such as through Windows Explorer.

Microsoft had an often questioned patent issued on its products in the mid-1990s when they added long filename support for Windows 95. Originally the FAT file system was limited to 11 characters, which consisted of an eight character name and a three character extension, separated by a period, such as “SIDEKICK.COM”. Names like “Side Kick.com” were not allowed at that time.

With Microsoft’s patent, the design extend that limitation to allow for long filenames such as “My favorite Document.doc”, which includes spaces and other previously disallowed characters. The patent explicitly states that both a short- and long-filename form would be stored physically on the disk in something called a directory entry, such as “MY_FAV~1.DOC” and “My favorite Document.doc”.

The Linux developers have devised a way to bypass the Microsoft patent. By storing only the short-form, or only the long-form (but not both) on the FAT file system, the patent is bypassed. In this way, they are able to provide full native mainline Linux kernel support to all users for their FAT disks, and without having to pay royalties to Microsoft.

However, there are some potential side effects here. Since both file forms are not updated, some older systems which look for both of them to test the validity of the file entry, may no longer work.

In addition, if the filename changes from “MYDOC.DOC” to “My New Document.doc” (changes from the short 8.3 to long-format), the old 8.3 entry will be filled with invalid data, and a new long-format entry will be created. However, Windows XP has a bug which under certain invalid character combinations, will cause the system to crash.

For those issues, Linux already provides an “msdos” file system, which enforces only the 8.3 naming convention, and will keep Windows and other OSes which rely on both forms, from crashing.

The patch was published last week and followed a previous attempt by Tridgell in May which disabled long filename creation entirely. While that patch was not well received, nearly every Linux user and developer today is going “Huh!” as they ponder the reality of such a simple, elegant solution.

The Linux Foundation has arranged for the patch to be reviewed by its multitude of patent attorneys. When and if it is finally approved, all mainline Linux distributions will receive the patch in future versions, allowing the FAT filesystems to be read/written to without fear of litigation by Microsoft — a possibility that has long hung over the heads of major Linux publishers, like Red Hat, SuSE, Debian and others.

Rick’s Opinion
YES! Score another point for the freedom of open-source. I’m telling you, there is nothing outside the realm of possibility if people are given half a chance to compete openly in the marketplace. And it’s creative solutions like these which will rise to the top very quickly in such an environment. Kudos, Andrew!

In addition to this work-around, everybody is pretty much in agreement that a neutral, open-standard file format needs to be created for all media forms in moving forward. This is not really even in dispute. However, for the time being the reality is this is a Windows world, and we must deal with that before we can move forward. Oh how I liked writing that last sentence.