Linux Patch Clears the Air For Use of Microsoft's FAT Filesystem
Ars Technica is reporting that a new kernel patch may provide a workaround to allow use of Microsoft's FAT file system on Linux without paying licensing fees. "Andrew Tridgell, one of the lead developers behind the Samba project, published a patch last week that will alter the behavior of the Linux FAT implementation so that it will not generate both short and long filenames. In situations where the total filename fits within the 11-character limit, the filesystem will generate only a short name. When the filename exceeds that length, it will only generate a long name and will populate the short name value with 11 invalid characters so that it is ignored by the operating system."
Is FAT used for anything other than USB drives?
When I read this my first impression, though admittedly not an informed one, was "you mean people pay to use FAT?" I wish patents were more like trademarks, where if you don't vigorously defend them and instead let them go for a while, you lose them and they become public domain. Wouldn't that be nice, to get rid of all these situations as well as all of the "submarine patents" in one fell swoop?
It is a miracle that curiosity survives formal education. - Einstein
As a long-time user of Linux who is currently using Microsoft Windows XP, the whole vfat (FAT with Win95 long file names) patent and how Microsoft has handled this patent makes me feel that maybe Microsoft is engaging in the same kind of monopolistic behavior that they engaged in when they destroyed Netscape in the 1990s.
I'm sure people know about Microsoft's patent violation lawsuit against TomTom; if you don't the Wikipedia is your friend. What a lot of people don't know is that Microsoft made some changes to Vista so that you can no longer easily use an unpatented filesystem like ext2 (Linux's 1990s file system which nicely enough is supported in Windows with a couple of different 3rd party drivers).
For me, it seems very suspicious that Microsoft made some changes to Vista that make it very difficult to use filesystems not patented by Microsoft around the same time they used licenses for their filesystems as a revenue source.
I posted a blog about this back in March and to quote that blog entry:
To allow USB drives, cameras, SD cards and more to work out of the box under Linux. With this patch you can distribute Linux without the fear of Microsoft suing you (like the did with TomTom)
Is FAT used for anything other than USB drives?
You say that like that's a small thing.
'Sensible' is a curse word.
Comment removed based on user account deletion
Media players. Hard drives, in computers where there are multiple OS's. Industrial equipment controllers. I bet you even some satellites use FAT.
It's ubiquitous because it's simple and until the NTFS drivers were fixed(read:not trashing your data), FAT was one of the only convenient formats for sharing data between Windows and Linux.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
Comment removed based on user account deletion
The reason that FAT is still around has more to do with compatibility than any kind of technical merit. Pretty much every version of Windows supports FAT, and most other operating systems can use it as well. I think most "smart" vendors have figured out that if they use FAT for their devices (music players, cameras, GPS units) then pretty much anyone will be able to use them. That's why it's important to have FAT support in Linux, no one is saying that you have to use it on your / partition though. :-)
Are you honestly that dense? That's like asking if CD drives are used for anything other than CDs.
Flash drives have replaced floppies as the primary small rewritable data storage medium. Not supporting them is as egregious as not supporting DVDs, which incidentally have issues that are on sturdier legal ground.
they want their obsolete file system back
Not much, but "USB Drives" covers a lot of devices. Most MP3 players and digital picture frames behave as USB drives, so do some satnav devices.
What am I missing here ?
Will Groklaw one day be reporting about MSFT v. SPI ?
when you're setting up your own filesystems, however... just use ntfs-3g and fs-driver. problems solved. just don't forget to use mke2fs -I 128
Don't know about you, but I like my USB drives to be small things.
Hopefully, soon, we can start using UDF instead of FAT. Cross-OS compatibility is pretty much there, though FAT's support is still the most broad.
This sounds dangerous to me. What if someone uses this to write to an SSD card that they plug into some cheap portable device (a media player for example) that doesn't implement the "standard" properly and gets confused by the data in the short filename when a long one is present? Or refuses to read half the files because it only likes short names (some cheap Chinese import MP3 players just use the short filename in displays) and half the files have names too long? The user won't blame their crap cheap little portable device they paid $3 for on eBay, they'll blame that there Linux thing because their copy of Windows can write things so the player understands.
Sometimes though, when you think you're being all smart, and you've formatted your USB-drive to FAT so you can use it easily in both Linux and windows. Then you start copying your DVD images or mkv / x264 movies onto the drive. 4 GB later: "out of disk space". "Huh? But this USB stick is like 16 GB! wait... DOH!"
The 4 GB file size limit can be a bit of a hassle at times.
I use FAT on my usb keys only because I want to be able to use them from Windows machines.
But in Windows Vista+ you can also format USB flash drives to UDF (you’ll have to use the command line FORMAT tool, the GUI frontend won’t show UDF as an option).
When formatted in UDF, the drive’s performance improves dramatically: on my usb key, untarring the linux kernel and then deleting it changed from taking a few hours to taking a few minutes.
UDF can be read/written under Linux and, unlike NTFS, it natively supports all UNIX features (including extended attributes), so for example you could boot Linux straight from a Windows-accessible USB drive without creating ext3 images on it, and without using userspace file system drivers.
So it could be a nice solution for Linux/Windows interoperability... but sadly Windows stops liking UDF file systems if Linux creates files on them (I don’t know what exactly makes Windows upset; when it happens, Windows’ CHKDSK says the file system is OK).
This will break the myriad of read-only implementations out there that only use short names, which is a lot more than you'd think. This means this can't be enabled by default on your average Linux.
It might help TomTom and the like, but it's not a cure for the patented portions of FAT. It's just a hack that might help some specific implementors. Kudos to the kernel developers for doing their best, but the real solution is to get the bogus patents invalidated.
Let me guess.. you are in your teens/early 20's..
You do realize that in the real world people play the prisoner's dilemma, right?
"His name was James Damore."
It's not FAT; it's just big-boned.
Don't know about you, but I like my USB drives to be small things.
Then why would you want them to be FAT?
There are several reasons to want to use FAT:
Multibooters store their files on FAT filesystems because they're supported by, in a word, everything. Want to share your files between FreeBSD, Linux, Windows, BeOS, and OS/2? FAT is your friend. I still keep most of my data on a vfat filesystem for this reason even though I haven't used Windows in aeons. When I switched from FreeBSD to Debian, I didn't have to worry about whether UFS support was included out of the box, or what package to install to get it, or whatever; all my data were on vfat, which is always available, always supported, on every OS.
People who carry data around on portable disks also use FAT, in case they need to access it from a friend's computer, a computer at work, a computer at the library, or cetera, which may not have the same operating system they use at home. I carry around a small Flash-ROM-based USB 2.0 Mass Storage Device on a lanyard, which I have formatted vfat. If I need to copy files onto it from a computer that's running an old version of Debian with no NTFS read/write support, I can. If I need to take those files and copy them onto a computer that's running the Windows Seven RC, I can. If I'm at a relative's house and they want to see the photos that I've got on there, and their computer is a Mac, it's no problem.
FAT is also simple, well documented, and well understood. If you're the sort of nerd who wants to reserve the possibility, in case anything goes wrong (say, an untimely power blink), of looking at the block device for the disk directly and *finding* that lost file, it's not very hard with FAT. (Yes, I actually did this a couple of times back in the DOS days. Successfully.)
Finally, a lot of people have old disks sitting around, containing data they want to keep, on FAT filesystems in many cases.
Cut that out, or I will ship you to Norilsk in a box.
(SFNDE = Short File Name Directory Entry)
.
Regarding the patent filed in 1993.
.
It seems that the aim is to implement a "different idea" than that expressed in Figure 6b. (free rego at freepatentsonline to see original PDF with figures)
.
What about all the references to "short filename including at most a maximum NUMBER OF CHARACTERS THAT IS PERMISSIBLE BY THE OPERATING SYSTEM."
Is the Linux Operating System limited to a only of 8.3 characters? To that effect, why does this patent apply to Linux at all?
.
I can't quite remember my history, but weren't long filenames (LFN) introduced with Windows 95 in 1995? Wasn't Win95 just a GUI layer on top of DOS and so bound by the filename length contraint of the DOS "OPERATING SYSTEM"? Wasn't it actually the Win95 GUI that interpreted and displayed the LFN?
Isn't Linux access to FAT different?
.
Even though the FAT filesystem was limited to 8.3 characters, don't you think that DOS was "hardcoded" to 8.3 characters. Thus it was a constraint of the "Operating System" that this patent was addressing. The Linux situation seems completely different. Linux does not have this constraint, thus the Linux "idea" for implemeting dual directory entries is different than the "idea" for Windows GUI on DOS as expressed in the given patent - ie thus the "idea" for Linux is compatability, whereas the "idea" for Windows was to get around the 8.3 constraint.
.
Fig 2 shows LFNDE alongside SFNDE. Is that required technically for compatability, or can they be stored apart?
Alternatively ONLY create long filename, then have some sweeper task come along and create the short filenames from the long ones.
.
It talks about only creating a LFN when it is longer than 8.3.
Well then, create a LFNDE "EVERY TIME".
.
The patent says "At a minimum, a short filename will be created."
Have linux do it differently, at a minimum create both a long and a short filename.
.
The patent describes using "both SFN APIs and LFN APIs".
Does linux have both or does it do it "differently" with just LFN APIs?
It looks like someone has forgotten that what is good for one's self is not necessarily good for everyone else.
It may be the best solution for Linux advocates, but it is probably not the best solution for the device manufacturers. 90% of their market uses Windows. If the manufacturers moved to a "new vendor-neutral format", they would break the automatic compatibility with 90% of their market and they would also have to ship driver disks to install the drivers needed to read and write the new format with every device. This would increase the cost of manufacturing and packaging as well as make it harder to use the devices.
Perhaps Linux supporters should stop being so self-centered and start thinking of the larger picture before making such statements.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
Hmm, I'm not so sure this is a good idea.....
How do simpler devices that write to FAT deal with it?
cameras, pdas, etc
All modern PDAs can typically deal with long filenames fully, so no problems there. They would read the long filenames properly from a FAT disk created with this Linux patch.
Digital cameras typically use short filenames exclusively (e.g. IMPC1234.JPG). They mostly only write files and don't read files other than those that they've created themselves. This patch doesn't affect filename reading, only filename writing, so cameras would work okay too.
MP3 players typically deal with long filenames as well, so no problems again, hopefully... as long as they obey the specs for reading FAT partitions.
So this patch should not interfere much with interoperability with modern accessory/embedded devices. Of course, the patch does remove some functionality... namely the ability to create nicely matched short filenames when you're also creating a long filename. But I do believe it's a fairly clever way to avoid this bullshit patent while maintaining interoperability.
It's important to understand that this patch DOES NOT permanently remove any functionality from the Linux kernel. It merely provides a kernel config option to disable full FAT operation. Depending on your jurisdiction/comfort level/Microsoft-hatred/etc. you can choose to enable/disable the patch.
My bicyles