Slashdot Mirror
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?
You say that like that's a small thing.
'Sensible' is a curse word.
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.
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.
FAT is hardly a submarine patent. MS has sued MANY manufacturers over their use of FAT in electronic devices and most companies end up reaching a licensing agreement and the lawsuit is dropped.
Thank you for correcting my ignorance on this matter.
Incidentally, the more I hear of things like this, the better I can understand why so many Europeans think it's absurd that the USA has software patents at all.
It is a miracle that curiosity survives formal education. - Einstein
The bottom line is that Microsoft is using its monopoly position as an operating system vendor to force third parties to license trivial but patented VFAT technology that is only useful for interoperability.
If that isn't abuse of their monopoly, I don't know what is.
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.
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.
Ext2/3 supports the use of xattrs that are perfectly adequate for storing ACLs and other such. In fact, however rarely it is used, that's how ACLs are supported in Linux. xattrs are also used to store SELinux data.
It is true enough that there probably aren't many windows .exes stored on ext2 other than for backup or sneakernet, but it does represent a needless limitation that appears to exist purely as an attempt to force 3rd parties to use MS's patented junk.
(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