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."
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)
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.
Hopefully, soon, we can start using UDF [wikipedia.org] instead of FAT. Cross-OS compatibility is pretty much there, though FAT's support is still the most broad.
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...
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.
Often, in this case, it's not just multiple OSes that need to access the filesystem, but also embedded devices. Think digital cameras, GPSes, that sort of thing, where the overhead of a journaling filesystem is pretty overkill, but it still needs to be accessed by full-blown OSes.
FAT is perfect for those devices, due to its lack of features.
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.
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?
You get my support if you add in something about a requirement that it should be possible to build a working example of whatever you're patenting using the patent documentation(you know, so that patents actually serve their stated purpose).
Well, they're almost like that in the USA. You can't claim any damages that occurred between your becoming aware of infringement and filing suit. Fortunately, not many FAT patents are still valid. Patents last at most 20 years, so anything from the DOS days is gone. The relevant ones here were included with Windows 95. I presume MS filed them before releasing '95, possibly even before releasing the betas, so they should expire in the next few years.
You can't claim any damages that occurred between your becoming aware of infringement and filing suit.
Sure you can. You can claim damages for damages that occurred between your becoming aware of infringement and filing suit. However, the other side can raise laches [wilmerhale.com] as a defense. If you delayed unreasonably in taking action, then the judge might bar your claim to earlier damages.
What is reasonable and what is not? You can't look at the patent statute to find out, laches are a judicial remedy for inequitable conduct. Thus, you have to go through Federal Circuit cases to find cases that are most similar (and probably distinguishable given a particular set of facts).
It would probably get very complicated in case where a third-party has allegedly infringed for some time, but the patent owner sued (or countersued) a new alleged infringer based on recent conduct. If the patent owner did not plan on suing the third-party, then why is unfair to wait until the recent conduct before suing the new alleged infringer?
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.
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.
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.
Actually, patents expire 20 years from the filing date. This means that (A) they only last 20 years (with some possible term extension of a few years) and (B) "submarine" patents are basically a thing of the past.
Under the old law, patents expired 17 years from issue so you could keep an application going with continuations for 20 years at the PTO and still have a 17 year term. Now if you kept an app going that long, you would come out with zero term.
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.
Yes, patents cover any imports. Also according to the statutes wording it is also a violation to manufacture, import, or distribute a kit composed of non-patented items if it violates a patent when assembled. So since the vendors have to include the source code, even if the code is compiled in such a way to avoid the patent the source itself would still be in violation of the patent statute. See US Code TITLE 35 PART III CHAPTER 28 S 271 (c). [cornell.edu]
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 [wikipedia.org]. 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 [ext2fsd.com] party drivers [fs-driver.org]).
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.
it can be shown, with Vista, that Microsoft removed compatibility for non-patented filesystems, forcing people to license Microsoft's patents, not because the patents are novel, but because the patented filesystems must be used for interoperability purposes
I was initially skeptical because of your abusive use of "unpatented" all over the place, as if this is solely about patents. You don't provide any clear links here, but 2 clicks away, I found this [fs-driver.org]:
The problem is caused by Vista's internals: There is some code that compares whether the name of the file system type is one of the following: "NTFS", "FAT", "FAT32", "CDFS", "NPFS", "MSFS" or "UDF". If there is a match, it is one of Microsoft's file system types and a lot of code is skipped in the Multiple UNC P
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.
ext2fsd and fs-driver both work on vista. and they'll both mount my ext3 filesystems, as long as i formatted them with the right inode size.
the issue you (eventually) link to basically says that all ext2/3 filesystems mounted on vista are the equivalent of noexec. 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. the permissions system on ext2/3 is totally wrong for windows anyway, so you'd never use it for, say, %ProgramFiles% or %SystemRoot%.
do not disable UAC.
the problem i have with vista's driver support is that on amd64 it requires them to be cryptographically signed by some sort of extortion outfit, or i have to press F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 up up enter every time i boot the system in order to get it to load the drivers i need.
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.
Actually, if you follow the links, it sounds like deliberate behaviour by Microsoft. If true Microsoft are asking for trouble with this. They change the behaviour for their own file system types, and generate an error for any other:
Quoting from the fsdriver.org site:
"Currently it is not possible to start a program on Vista if UAC is enabled and the program's executable is stored on an Ex2/Ext3 volume. An "invalid parameter" message box appears, but the program does not start.
UAC is the feature of Vista that prompts the user to elevate the user privileges to administrator level when necessary. UAC is enabled by default. It is not recommended to disable it.
The problem is caused by Vista's internals: There is some code that compares whether the name of the file system type is one of the following: "NTFS", "FAT", "FAT32", "CDFS", "NPFS", "MSFS" or "UDF". If there is a match, it is one of Microsoft's file system types and a lot of code is skipped in the Multiple UNC Provider (MUP) implementation of Vista. If the file system type is a third-party type, for example "Ext2", some code runs in the MUP of Vista that always generates an ERROR_INVALID_PARAMETER error status code due to a bug of Vista."
1. In a computer system having a processor running an operating system and a memory means storing the operating system, a method comprising the computer-implemented steps of:
(a) storing in the memory means a first directory entry for a file wherein the first directory entry holds a short filename for the file, said short filename including at most a maximum number of characters that is permissible by the operating system;
(b) storing in the memory means a second directory entry for a the file wherein the second directory entry holds a long filename for the file and wherein the second directory entry includes an attributes field which may be set to make the second directory entry invisible to the operating system and the step of storing the second directory entry further comprises the step of setting the attributes field so that the second directory entry is invisible to the operating system, said long filename including more than the maximum number of characters that is permissible by the operating system; and
(c) accessing the first directory entry with the operating system.
Claim 1 of the '352 patent reads:
1. In a computer system having a storage, a directory service for accessing directory entries and a file system that uses the directory entries to access files, a method, comprising the computer-implemented steps of:
(a) creating a first directory entry for a file wherein the first directory holds a short filename for the file and the location of the file;
(b) creating a second directory entry for the file wherein the second directory entry holds at least one portion of a long filename having a fixed number of characters and a signature that identifies that the second directory entry holds a first portion of the long filename;
(c) storing the first directory entry and the second directory entry on the storage among the directory entries used by the directory service; (d) accessing the second directory entry by the directory service to access the file; and (e) creating and storing in the storage a sequence of at least one additional directory entry for holding a next sequential portion of the long filename.
It will be interesting to see what the Supreme Court has to say about the scope of patent-eligible subject matter in the upcoming Bilski case. It will probably be a year or two before we get a decision. http://www.patentlyo.com/patent/2009/06/bilski.html [patentlyo.com]
Come up with a replacement that allows reading and writing without any FS-specific actions to be taken by the user, has low administration overhead and has native first-class support by every operating system and we can talk about FAT being obsolete. Right now FAT32 is the most modern, most advanced file system in its class (the class of high-compatibility general-purpose filesystems, which consists entirely of FAT16 and FAT32).
Wrong. vfat is not reverse-engineered. Microsoft documented it quite well enough to implement both it and FAT. You may be thinking of NTFS.
Also nobody is concerned about the C# language itself, but about the *libraries* that programs use. You are basically claming that there is no problem cloning Windows because most software for it uses C++.
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.
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.
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 s
(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.
The Linux Foundation says that the best solution at this point is for vendors to ditch FAT and come up with a new vendor-neutral format that can be used without having to pay licensing fees.
An industry-wide shift towards an open royalty-free format in the hardware space could potentially liberate device makers from this dependence on Microsoft's encumbered technology.
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.
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.:-)
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.
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,
All it requires then is a single unified network file system that's 100% reliable, and doesn't bizarrely fail for more reasons than there are life forms on earth...
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.
Can someone explain to me why this is important? (Score:4, Interesting)
Is FAT used for anything other than USB drives?
Re: (Score:3, Informative)
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.
Parent
Re:Can someone explain to me why this is important (Score:5, Funny)
Parent
Re:Can someone explain to me why this is important (Score:5, Funny)
Don't know about you, but I like my USB drives to be small things.
Then why would you want them to be FAT?
Parent
Re:Can someone explain to me why this is important (Score:5, Informative)
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.
Parent
Re:Can someone explain to me why this is important (Score:5, Interesting)
Parent
Re: (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: (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: (Score:3, Interesting)
The poster to whom I originally replied mentioned cross-OS compatibility. I think the scope was pretty clear at that point.
UDF is pretty well supported isn't it?
Re: (Score:3, Informative)
Often, in this case, it's not just multiple OSes that need to access the filesystem, but also embedded devices. Think digital cameras, GPSes, that sort of thing, where the overhead of a journaling filesystem is pretty overkill, but it still needs to be accessed by full-blown OSes.
FAT is perfect for those devices, due to its lack of features.
Re: (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: (Score:3, Insightful)
Patents and Trademarks (Score:5, Informative)
Re:Patents and Trademarks (Score:5, Interesting)
You get my support if you add in something about a requirement that it should be possible to build a working example of whatever you're patenting using the patent documentation(you know, so that patents actually serve their stated purpose).
Parent
Re: (Score:3, Insightful)
Re:Patents and Trademarks (Score:5, Interesting)
Sure you can. You can claim damages for damages that occurred between your becoming aware of infringement and filing suit. However, the other side can raise laches [wilmerhale.com] as a defense. If you delayed unreasonably in taking action, then the judge might bar your claim to earlier damages.
What is reasonable and what is not? You can't look at the patent statute to find out, laches are a judicial remedy for inequitable conduct. Thus, you have to go through Federal Circuit cases to find cases that are most similar (and probably distinguishable given a particular set of facts).
It would probably get very complicated in case where a third-party has allegedly infringed for some time, but the patent owner sued (or countersued) a new alleged infringer based on recent conduct. If the patent owner did not plan on suing the third-party, then why is unfair to wait until the recent conduct before suing the new alleged infringer?
Parent
Re:Patents and Trademarks (Score:5, Informative)
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.
Parent
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.
Parent
Re: (Score:3, Informative)
Re: (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:Patents and Trademarks (Score:5, Informative)
Actually, patents expire 20 years from the filing date. This means that (A) they only last 20 years (with some possible term extension of a few years) and (B) "submarine" patents are basically a thing of the past.
Under the old law, patents expired 17 years from issue so you could keep an application going with continuations for 20 years at the PTO and still have a 17 year term. Now if you kept an app going that long, you would come out with zero term.
Parent
Re: (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.
Re:Patents and Trademarks (Score:5, Informative)
Yes, patents cover any imports. Also according to the statutes wording it is also a violation to manufacture, import, or distribute a kit composed of non-patented items if it violates a patent when assembled. So since the vendors have to include the source code, even if the code is compiled in such a way to avoid the patent the source itself would still be in violation of the patent statute. See US Code TITLE 35 PART III CHAPTER 28 S 271 (c). [cornell.edu]
Parent
Is Microsoft engaging in their 90s behavior? (Score:5, Interesting)
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 [wikipedia.org]. 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 [ext2fsd.com] party drivers [fs-driver.org]).
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 [blogspot.com] and to quote that blog entry:
Re: (Score:3, Interesting)
I was initially skeptical because of your abusive use of "unpatented" all over the place, as if this is solely about patents. You don't provide any clear links here, but 2 clicks away, I found this [fs-driver.org]:
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.
Parent
Re:Is Microsoft engaging in their 90s behavior? (Score:5, Informative)
ext2fsd and fs-driver both work on vista. and they'll both mount my ext3 filesystems, as long as i formatted them with the right inode size.
the issue you (eventually) link to basically says that all ext2/3 filesystems mounted on vista are the equivalent of noexec. 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. the permissions system on ext2/3 is totally wrong for windows anyway, so you'd never use it for, say, %ProgramFiles% or %SystemRoot%.
do not disable UAC.
the problem i have with vista's driver support is that on amd64 it requires them to be cryptographically signed by some sort of extortion outfit, or i have to press F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 F8 up up enter every time i boot the system in order to get it to load the drivers i need.
Parent
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.
Parent
Re:Is Microsoft engaging in their 90s behavior? (Score:5, Informative)
Actually, if you follow the links, it sounds like deliberate behaviour by Microsoft. If true Microsoft are asking for trouble with this. They change the behaviour for their own file system types, and generate an error for any other:
Quoting from the fsdriver.org site:
"Currently it is not possible to start a program on Vista if UAC is enabled and the program's executable is stored on an Ex2/Ext3 volume. An "invalid parameter" message box appears, but the program does not start.
UAC is the feature of Vista that prompts the user to elevate the user privileges to administrator level when necessary. UAC is enabled by default. It is not recommended to disable it.
The problem is caused by Vista's internals: There is some code that compares whether the name of the file system type is one of the following: "NTFS", "FAT", "FAT32", "CDFS", "NPFS", "MSFS" or "UDF". If there is a match, it is one of Microsoft's file system types and a lot of code is skipped in the Multiple UNC Provider (MUP) implementation of Vista. If the file system type is a third-party type, for example "Ext2", some code runs in the MUP of Vista that always generates an ERROR_INVALID_PARAMETER error status code due to a bug of Vista."
source: http://www.fs-driver.org/relnotes.html [fs-driver.org]
Parent
The patents (Score:5, Informative)
Two of the patents are:
USPN 5,579,517 [uspto.gov] and USPN 5,758,352 [uspto.gov]
Claim 1 of the '517 patent reads:
Claim 1 of the '352 patent reads:
It will be interesting to see what the Supreme Court has to say about the scope of patent-eligible subject matter in the upcoming Bilski case. It will probably be a year or two before we get a decision.
http://www.patentlyo.com/patent/2009/06/bilski.html [patentlyo.com]
the 80's called (Score:3, Funny)
they want their obsolete file system back
Re: (Score:3, Informative)
MSFT can't give out VFAT, but can give out C#/Mono (Score:5, Interesting)
What am I missing here ?
Will Groklaw one day be reporting about MSFT v. SPI ?
Re: (Score:3, Informative)
Wrong. vfat is not reverse-engineered. Microsoft documented it quite well enough to implement both it and FAT. You may be thinking of NTFS.
Also nobody is concerned about the C# language itself, but about the *libraries* that programs use. You are basically claming that there is no problem cloning Windows because most software for it uses C++.
I predict incompatabilities (Score:4, Insightful)
Have you ever tried UDF on a USB flash drive? (Score:5, Informative)
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).
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: (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 s
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?
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.
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. :-)
Parent
Re:Who in their right mind would want to use FAT? (Score:4, Informative)
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
Parent
Re: (Score:3, Informative)
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.
Be nice. (Score:4, Funny)
It's not FAT; it's just big-boned.
Parent
Re: (Score:3, Informative)
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,
Re: (Score:3, Funny)
All it requires then is a single unified network file system that's 100% reliable, and doesn't bizarrely fail for more reasons than there are life forms on earth...
Re: (Score:3, Insightful)
wouldn't the sanitizing program stand in violation of the patent?
Re:It's time to show MS the power of *nix (Score:5, Funny)
You do realize that in the real world people play the prisoner's dilemma [stanford.edu], right?
Parent
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.
Parent