Linux Patch Clears the Air For Use of Microsoft's FAT Filesystem 272
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."
Re:Can someone explain to me why this is important (Score:5, Insightful)
Is FAT used for anything other than USB drives?
You say that like that's a small thing.
Re:Patents and Trademarks (Score:3, Insightful)
Re:Who in their right mind would want to use FAT? (Score:5, Insightful)
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. :-)
Re:Can someone explain to me why this is important (Score:3, Insightful)
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.
Re:Can someone explain to me why this is important (Score:3, Insightful)
A future bug (Score:1, Insightful)
If this patch is ever widely deployed, Microsoft will change their operating system to recognize and reject it. They won't admit to any intention even after the fact -- it was only a bug.
Re:Patents and Trademarks (Score:5, Insightful)
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.
Re:Is Microsoft engaging in their 90s behavior? (Score:5, Insightful)
If that isn't abuse of their monopoly, I don't know what is.
I predict incompatabilities (Score:4, Insightful)
Re:or heres a great idea (Score:3, Insightful)
wouldn't the sanitizing program stand in violation of the patent?
Re:Patents and Trademarks (Score:3, Insightful)
I wish copyrights were like patents and expired after 20 years instead of the unconstitutionally unlimited time thay do now. If patents were like trademarks they would be worse than copyright and never expire.
Bad idea (Score:4, Insightful)
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.
Re:Is Microsoft engaging in their 90s behavior? (Score:4, Insightful)
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.
Re:Patents and Trademarks (Score:3, Insightful)
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.
Seriously i hope distros ship dumbed down "us versions" of packages to avoid stupid software patents, because i sure as hell don't give a flying fuck about infringing this patent in the UK. Once it's clear that software patents are hurting US companies, it wont take long for SIGs in congress to sort the problem out, and given the current economic climate bullying the EU to be as retarded as the US (in this respect, we sure as hell already are in other areas) isn't an option.
Re:Can someone explain to me why this is important (Score:3, Insightful)
I don't see any indication that UDF supports journaling or anything else to maintain filesystem integrity--is that the case? If this is true, I don't see how it will be suitable for general filesystem use....
Yeah, but if it's to be used as a replacement for FAT...
Re:May I be the first to say... (Score:2, Insightful)
Re:Bad idea (Score:3, Insightful)
It only breaks implementations that only support short names, if you write files with long names to the filesystem and rely on them ending up with LONGNA~1 type filenames.
If your filenames are all 8.3 and you write them to a disk for your implementation that only understands 8.3, everything still works. If your filenames are long, you write them to a disk for your implementation that only understands 8.3, but you don't make any assumptions about what the filenames will be when converted to 8.3, everything still works.
Re:Is Microsoft engaging in their 90s behavior? (Score:2, Insightful)
interoperability is not trivial.
Re:Can someone explain to me why this is important (Score:3, Insightful)
If so, wouldn't it be nicer if they could change to something better?
Depends what you mean by "better" - for many situations where FAT is used, you don;t *want* stuff like journalling because you're dealing with very low power embedded systems.
Re:Who in their right mind would want to use FAT? (Score:2, Insightful)
How is this Insightful? It's a troll. Nothing more. The GP did nothing but offer a solution. Yes, it is cryptic for the newb, but this wasn't for a newb audience.
A _LOT_ of people that I deal with do not comprehend what an smtp server is. I still have to tell them what to fill in the little text box. As far as I can tell they still don't know what it is, and yet, somehow, they are using their email client.
other means of avoidance? (Score:3, Insightful)
(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?
Comment removed (Score:3, Insightful)
The best solution for whom? (Score:4, Insightful)
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.
Don't understand how this works around the patent (Score:3, Insightful)
The patent is (or should not be) on the obvious parts of the system. There is a clever thing in VFAT, in that they use hidden "volume label" directory entries to store the long name, and this work-around does not change that.
This is not just long filenames (unless the patent system is broken much worse than anybody thinks). It is blatently obvious how to add long filename support to a file system that has short filenames. However the "obvious" solution would be to use a single hidden file to store all the names. Microsoft chose another solution, and for a good reason (their solution has an advantage that if an "old" system deletes all the files in a directory, the directory looks empty. A hidden file would either be too easy to delete by accident or would be "locked" and thus the old system would be unable to empty the directory).
It is also blatently obvious that an 8.3 replacement filename must be made for the file, so that can't be patented. They may have patented the pattern but I'm fairly certain that any unique pattern of characters with the same extension would not break any software (they could have made a system where "part" of the long filename is stored in the 8.3 name, but they did not because they were probably worried about handling collisions of these short names, or just rushed with their implementation).
So I really don't see how this works around the actually patentable part of this, since the use of volume label directory entries is still being done.
It also appears that *reading* the long filenames is allowed without a license. So anybody can read these disks.
My suggestion would be to use a new method to store the long names. Users of Windows looking at the disk would see only the short names. People say that the users will blame Linux for that, but they are seriously underestimating the stupidity of users, they will blame the Windows machine, since when they put the disk back in the Linux machine the filenames work!
Re:Is Microsoft engaging in their 90s behavior? (Score:1, Insightful)
i don't think it is accurate to describe that as a significant issue. i don't know many people who keep substantial quantities of windows executables on their linux drives.
Many cross-platform .Net/Mono developers would like that.
Re:May I be the first to say... (Score:5, Insightful)
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.
Re:other means of avoidance? (Score:3, Insightful)
Uh, no.
The FAT file system stores 11 characters per file name in the directory entry, period. By convention, these are allocated to eight file name characters and three extension charcters. These are stored as 8-bit bytes.
No, Windows 95 is not a GUI on DOS. All Windows versions before 95 were that. Windows 95 introduced several new concepts such as the VxD and a different virtualization structure. Yes, Windows 95 through Windows Me had a primarily 16-bit kernel and a few 32-bit extensions and much of the 16-bit kernel had it roots in DOS. But it was a lot more than a GUI on DOS.
Support was added to DOS 6 for long file names, using exactly the same strategy as Windows 95.
The long file name implementation uses additional directory entries, beyond the base short file name entry, to hold a Unicode file name. The base short file name contains the starting cluster number of the file data, so it is vital that there is a short file name entry. The entries used to contain the long file name have file name bytes occupying those locations.
The long file name can occupy multiple directory entries, but they must follow the short file name - there is no pointer. So the long file name is just known to be in the following entries until the next short file name entry is encountered.
Sure, you could come up with a different way of doing it. It would be simpler to just make the directory entries bigger. But the question is how do you write it such that the Windows implementation can read the file system. There are very few options for flexibility to maintain this compatibility. The basic thing is that long file names are a very simple add-on to the FAT file system that has existed for a long time. This allows full read and write compatibility even if the writer has no knowledge of long file names.
Re:In other words... (Score:2, Insightful)
I keep seeing this "broken design" bullshit, but what they did is patent a method to maintain backward compatibility with a filesystem implementation that was initially designed to work on computers that various Unix implementations wouldn't even consider booting on. It might be hard to remember when 10MB was a big hard drive, but that's the legacy of FAT. Limited file names were a smart idea because it kept the bookkeeping small and predictable. Since Microsoft was extremely successful with DOS and many people created applications that various users needed to continue running, the VFAT implementation was a pretty good compromise to move forward while allowing things to keep working.
I guess if you spin it the zealot way it sounds worse, and I'll probably get accused of being a shill for not bashing Microsoft, but really there's just no need for the anger.
Re:Who in their right mind would want to use FAT? (Score:3, Insightful)
If you are unable to browse the Synaptic package manager to install a program then you must be the worlds biggest fucking idiot.
Years in tech support and you still can't use a point and drool interface.
What a maroon.