Slashdot Mirror
Microsoft to Charge for FAT File System
pario writes "According to Microsoft, the Redmond company is going to charge a license fee for any product that is formatted in FAT by the manufacturer. Any manufacturer of compact flash memory cards or digital cameras may end up paying Microsoft as much as $250,000 for the use of the file format. The FAT File System is covered by several US patents."
I see nothing wrong with it. They own the patents, so they have the right to sell it to whoever pays. BTW, slashdot post is a bit misleading.
"Pricing for this license is US$0.25 per unit with a cap on total royalties of $250,000 per licensee."
The $250K is the cap; that means, that is the maximum amount they will charger per license holder for the use of the FAT. Just thought it came across incorrectly.
A blog like any other.
Is there a win32 ext2/3 filesystem driver out there anywhere?
Searching for "win32 ext2" yields this as the first link.
WWTTD?
Perhaps now we'll see manufacturers adding [ext2/3/your favorite flavour of a fs] to their products.
Esp with camera's gaining support for the picture tranfer protocol (PTP), they are becomming more and more filesystem agnostic. Other devices may as well...
the pun is mightier than the sword
Where do you get your information? That number is inaccurate:
NTFS, FAT, FAT32
A blog like any other.
If you RTFA (Wait, what was I thinking! This is /.) you would find that this only applies to consumer electronics (DVD players, TV's, etc.) and portable memory devices, like Compact Flash and those little USB memory sticks. At least for right now. And it only counts if it comes preformatted from the mfr.
I suspect this will drive most manufacturers to not format their media, or it will drive them to an open format, like jffs.
In the USA, we like stuff watered down, like beer, television, and freedom.
They didn't file any till 1995. Kinda clever, really - don't even bother patenting it untill you see if it's going to be popular. All the benefits of the submarine patent, but without the up front patent fee!
RTFA. (Go ahead, give me the old "You must be new here" - joke. :)
:)
The linked article does not mention home computers. Microsoft wants license fees from:
1) Manufacturers of solid state removeable memory devices
and
2) Manufacturers of certain types of consumer electronics that use the FAT file system:
portable digital still cameras
portable digital video cameras
portable digital still/video cameras
portable digital audio players
portable digital video players
portable digital audio/video players
multifunction printers
electronic photo frames
electronic musical instruments
standard televisions
Do you think you'll ever buy one of those? Then it'll affect you.
"I'd rather have a full bottle in front of me than a full frontal lobotomy"
http://www.vcnet.com/bms/departments/innovation.ht ml
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
As I read the license options, this applies only to devices that come pre-formatted as FAT. No mention of software. Limiting the ability of others to write FAT-compatible software would be a bad strategic move on MS's part - anyone who currently has another OS interoperating with Windows via FAT may be just as likely to ditch Windows as they are the "other" OS.
Umm no its because the patents don't cover FAT16, only FAT32 which WAS developed between 90-95 for Windows 95
Do these devices really need compatibility with "dead" operating systems?
The second patent seems to another concerning filename formats. I haven't bothered to look at the other 2.
That doesn't mean they won't go there, just that they haven't yet. Still, the typical knee-jerk reactions here are as yet unwarrented.
Patents can be enforced at any time by the patent owner. They can also be selectively enforced (see IBM saying that SCO is violating their patents while not going after anyone else that uses it).
So, how can they expect to enforce this? All of their patents cover VFAT issues. AFAICT, FAT16 is unencumbered.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
It's very good move by MS.
/. -- when you're done writing around 200k files to flash media it was already past erasure limit for those sectors at the beginning i.e. media was destroyed.
FAT is a terrible format for Flash media, because it constantly updates some variables in first several sectors of the disk. The effect was mentioned some time ago on
So it might actually give some incentive for vendors to move to JFFS or similar FS _designed_ with this flash-specific limitation in mind.
rrw
Bastard Operator From 193.219.28.162
It's not like they provide very much information, but here are the patent abstracts, plus links to the full patents. They sure don't seem interesting, and they all seem to deal with the coexistence of long and short filenames. All of this wouldn't be patentable in Europe.
United States Patent 5,579,517
Reynolds , et al. November 26, 1996
Common name space for long and short filenames
Abstract
An operating system provides a common name space for both long filenames and short filenames. In this common namespace, a long filename and a short filename are provided for each file. Each file has a short filename directory entry and may have at least one long filename directory entry associated with it. The number of long filename directory entries that are associated with a file depends on the number of characters in the long filename of the file. The long filename directory entries are configured to minimize compatibility problems with existing installed program bases.
United States Patent 5,745,902
Miller , et al. April 28, 1998
Method and system for accessing a file using file names having different file name formats
Abstract
A multiple file name referencing system stores multiple file names in a file. These multiple file names include an operating system formatted file name and an application formatted file name. When an operating system formatted file name is created or renamed, the multiple file name referencing system automatically generates an application formatted file name having a potentially different format from, but preserving the extension of, the operating system formatted name. The multiple file name referencing system similarly generates an operating system formatted name upon creation or renaming of an application formatted name. A B-tree is provided which contains an operating system entry for the operating system formatted name and an application entry for the application formatted name, each entry containing the address of the same file to which both names refer. The multiple file name referencing system converts the operating system formatted file name to the application formatted file name by accessing the B-tree with reference to the operating system entry, and vice versa. As a result, either file name can be used to directly reference the file without requiring additional file name translation.
United States Patent 5,758,352
Reynolds , et al. May 26, 1998
Common name space for long and short filenames
Abstract
An operating system provides a common name space for both long filenames and short filenames. In this common namespace, a long filename and a short filename are provided for each file. Each file has a short filename directory entry and may have at least one long filename directory entry associated with it. The number of long filename directory entries that are associated with a file depends on the number of characters in the long filename of the file. The long filename directory entries are configured to minimize compatibility problems with existing installed program bases.
United States Patent 6,286,013
As long as they don't use both long and short filenames in their implementation, they won't violate those patents. At least that's what the abstracts make me believe. See my other post, where I put the abstracts.
WinFS is a layer on top of NTFS. WinFS does NOT replace NTFS as the lowest layer on the disk. Why should they create a totally new filesystem when NTFS is quite good at what it does?
NTFS supports many features that go unused >90% of the time, such as multiple file streams. WinFS will more fully use features present in NTFS as part of its operation.
In theory, you could use any filesystem you desire as all applications that run under DOS are supposed to use its system calls for disk I/O.
However, since FAT is a trivial to understand filesystem there are disk utilities that bypass the standard DOS I/O system calls and access the disk directly. These utilities would obviously fail to understand any file system other than one that was FAT based.
Otoh, patents do not make this discrimination. The only exception is that if you used a patented technique before it was patented (but you never published it, so your work cannot be considered as prior art), then you can continue to use this technique *for personal use* even after the patent has been granted (which excludes any commercial use afaik, though I'm not certain of this). If you independently came up with it after the patent was granted, you're completely out of luck.
The reasoning is that patents exist to protect big investments in R&D, which generally wouldn't have occurred if there was no way to safeguard the results from imitation with patents. So patents are considered as some kind of necessary evil (temporary monopolies), required to promote innovation and disclosure. Of course, in case of software patents this reasoning is almost never true and you are pretty much stuck with only the negative sides.
Donate free food here
"... volumes bigger than 2gb..."
This should be file sizes bigger than 2 Gigabytes.
If you looked it up, you'd see that the patents listed on microsoft's page are not for FAT itself, but for long filename extensions to it.
The patents listed were filed in '92, 95, 96, and 97. I haven't looked into the details of the patents, but I assume the date those features were published would be during the mareting of windows 95, so the first 2 at the very least are within the 1 year publish-file grace period.
Your credit card information wants to be free.
I agree, though, that this might be a way to nudge industry away from FAT over time, presumably to another niftier (and pricier) Microsoft-supplied alternative. Just thinking out loud here, but if you think of Windows PC's interfacing with consumer electronics gear using FAT, would it make life simpler for Microsoft to have them using NTFS or, in the distant future, the Longhorn equivalent?
Stop by my site where I write about ERP systems & more
The validity of one claim typically does not invalidate the others. My patent lawyers call this a layered approach, where the first claims are purposely broad in an attempt to grab as much IP ground as possible. Subsequent numbered claims in the patent are become more specific. They take this land grabbing approach essentially because they can.
ISO9660 is not writable in any useful sense.
CDs use multiple sessions to change previous writes.
CD-RW's get completely blanked before reuse.
Maybe that UDF filesystem would work though?
Carpe Daemon
"Microsoft needs to defend this patent lest they lose it."
You're confusing Trademark law with Patent law; Trademarks must be defended lest they be abandoned, patents can be enforced against some, all, or none of those infringing on the patent at the patent-holder's whim. The entire practice of "defensive patents" rests on this.
U.S. Patent #5,579,517 Common name space for long and short filenames
An operating system provides a common name space for both long filenames and short filenames. In this common namespace, a long filename and a short filename are provided for each file. Each file has a short filename directory entry and may have at least one long filename directory entry associated with it. The number of long filename directory entries that are associated with a file depends on the number of characters in the long filename of the file. The long filename directory entries are configured to minimize compatibility problems with existing installed program bases.
U.S. Patent #5,745,902 Method and system for accessing a file using file names having different file name formats
A multiple file name referencing system stores multiple file names in a file. These multiple file names include an operating system formatted file name and an application formatted file name. When an operating system formatted file name is created or renamed, the multiple file name referencing system automatically generates an application formatted file name having a potentially different format from, but preserving the extension of, the operating system formatted name. The multiple file name referencing system similarly generates an operating system formatted name upon creation or renaming of an application formatted name. A B-tree is provided which contains an operating system entry for the operating system formatted name and an application entry for the application formatted name, each entry containing the address of the same file to which both names refer. The multiple file name referencing system converts the operating system formatted file name to the application formatted file name by accessing the B-tree with reference to the operating system entry, and vice versa. As a result, either file name can be used to directly reference the file without requiring additional file name translation.
U.S. Patent #5,758,352 Common name space for long and short filenames
An operating system provides a common name space for both long filenames and short filenames. In this common namespace, a long filename and a short filename are provided for each file. Each file has a short filename directory entry and may have at least one long filename directory entry associated with it. The number of long filename directory entries that are associated with a file depends on the number of characters in the long filename of the file. The long filename directory entries are configured to minimize compatibility problems with existing installed program bases.
U.S. Patent #6,286,013 Method and system for providing a common name space for long and short file names in an operating system
An operating system provides a common name space for both long filenames and short
Nothing for 6-digit uids?
The GIF file format isn't patented. You can't have a patent on file formats, the order of fields in a sector, etc. There is nothing innovative in that.
... instead of following the compression algorithm.
The hardware process of the LZW compression algorithm was what as patented. You can write GIF files without using compression (literal, clear dictionary, literal, clear dictionary
Here, Microsoft's patents relate to algorithms for fitting long filenames onto a file system that only supports short filenames. They do NOT have a patent on the (V)FAT filing system. However, in working with those filing systems you may need to use algorithms which Microsoft managed to patent.
Does my bum look big in this?
yes NTFS is indeed covered under many patents and trademarks.
...as witnessed by the article yesterday on using windoze DLLs in *NIX to get write access to NTFS media...
the format has not fully been determined, nor has it been fully released by MS.
It would not be hard for device makers to switch to ext2. People only buy CF cards for devices that use them. All of the devices that use them come with Windoze drivers and programs to manipulate them. Each of these device makers could decide to switch to the superior ext2 file system and include all the software needed, if they don't just have that as an option on the device itself. This would simplify their devices and give them greater flexibility in their software. The only problem would be that people with older devices will have trouble sharing their CF media between the devices. That's no big deal when you consider how cheap CF is now and how much better the newer devices are. People who buy devices already have to go through the pain and suffering of windoze program installation, formatting the media is a small pain next to that. CF makers would come around quickly.
M$, you have screwed up trying to extort people for your ugly kludge.
Friends don't help friends install M$ junk.
Unh... you think you can. Do you know all the applicable patents? I sure don't. MS may well have a patent on something about *.doc files, and if they do, then you can't write one, clean room or not, without infringing on it. You're just probably below their radar.
Remember, there is no requirement that a patent be enforced. You can do it when, how, and as you choose. (Well, ok. You've got to use lawyers rather than thugs.)
I think we've pushed this "anyone can grow up to be president" thing too far.
The Dakota Disposable Digital uses the FAT12 file system internally (just like all smart-media products), but this isn't really noticible though its interface to the outside world. The only externally visibile part is the directory entry, of which they don't use all the fields. The FAT table & directories (it does use 2 directories internally) is totally hidden from the interface.
HIV Crosses Species Barrier... into Muppets
My guess is Microsoft is trying to generate some buzz same as SCO.
#5,579,517
#5,745,902
#5,758,352
#6,286,013
(For Those too Lazy to read The Article)
The Geek in Black
I know my BCD's (when I'm Sober)
My first and best guess would be trough their assess. No more, no less.
Never forget that this is the company that have claimed wonderfull things like 'a web browser is part of the system kernal' and that 'a media player is inseperable from a operating system'.
Any thing coming out of that company should be taken with a truckiload of salt.
Not Buzzword 2.0 compliant. Please speak english.
The problem with it is, their implementation of long filenames for FAT was in the hands of people outside of Microsoft well before the one-year prior drop-dead date for the application. Before it was Windows 95, it was codenamed Chicago and it was available to ISV's beginning of 1994 (as in it was available to developers outside of the company BEFORE April 24 1994...) - I know, I was part of that beta program. It does not matter WHAT you have with those people in the way of non-disclosure, they're customers and the moment you put an improvement in the hands of anyone outside of your company, the clock on the filing date starts ticking because you've revealed it to the world as far as the law is concerned.
The first patent, at least, is invalid by their OWN prior art.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
BZZZT!!! Wrong!
THe original FAT code was written by Tim Patterson, an employee of Seattle Computer Products (SCP) at that time. The original x86 DOS, called, alternately Q-DOS or 86-DOS was marketed by SCP to go along with thier two board 8086 CPU set. This was in 1980 or 1981, and you can find ads for this product in BYTE magazines from the period.
Actually, you are alittle off. QDOS was developed by Tim Patterson of Seattle Computer Products. He developed this in his "spare time". QDOS was called "Quick and Dirty Operating System", of which he modeled off CP/M, the popular operating system at the time. He had essentially "reveresed engineered" CP/M, using the CP/M manual as his "specs" for his OS, QDOS.
When IBM tried to buy the rights to use CP/M from Digital Research Inc (DRI), Gary Kildall wasn't available, and his wife and lawyers did not like the non disclosure agreement presented by IBM. So DRI sent IBM packing.
IBM then went back to Microsoft since it was Microsoft who sent IBM to DRI. At the time, IBM had only contracted Microsoft to do the languages and some tools for the IBM PC. IBM needed an OS to run on the PC. Microsoft then "seized" the opportunity and told IBM that they would supply an OS for the system. As "luck" would have it, someone at Microsoft knew about Tim Patterson's QDOS and they pursued it. Microsoft then bought QDOS for $50K from Tim Patterson and Seattle Computer Products. This was the "deal" of a lifetime, since from there DOS royalties jump started the Microsoft engine.
For more info, check History of DOS (PC Museum), one of many sources of information on the subject. Or check Cringely's "Triumph of the Nerds" documentary series.
if (!sig) { printf("Signature Unavailable\n"); }
What are you talking about? How about this 2.2 GB microdrive I want to get for my digital camera? Are you telling me that thing isn't organized into blocks? Right.
There's a reason the flash standards specify block devices instead of treating the thing as a (relatively slow) RAM stick. It's a form factor and data access protocol, not a particular media type. Making it use blocks is the best way to support the broadest range of storage technologies.
NTFS is actually just a fancy variation of the FAT filesystem.
I'm not kidding. It's like ext3 is to ext2 (except in an incompatible way).
You're thinking of trademarks. [The doctrine of laches] does not apply to patents.
Oh really?
Hard drives aren't what Microsoft is after. They're after things like USB keychains, Compact Flash cards, etc. There are a lot more of those sold than there are external HD's, and they come pre-formatted to work in digital cameras.
;-)
Could be "over a barrel" syndrome because you have lots of devices like digital cameras that can read FAT and nothing else. I doubt many average joes have the ability to flash their camera BIOS to get them to read reiserfs or xfs
A Patent, in and of itself, doesn't care about those things. So, in actuality, Microsoft could ask for royalties on each and every Patent on this list and legitmately so unless each are invalidated or your implementation is somehow found to not infringe.
Let's go over the Patents one by one, shall we?
5,579,517 - Common name space for long and short filenames. Filed for on April 24, 1995. This one only impacts you if you're using a Common Name Space for long and short filenames. Basically, the scheme they deployed for Chicago- references a preferred embodiment for MS-Dos 5.0 that was apparently handed to the USPTO as part of the application. Very much likely to be invalidated, though, by their OWN prior art release of Chicago to the world in December of 1993. This describes a scheme for handling long and short filenames correctly. If it's not invalidated, you might run afoul of it trying to do a VFAT type implementation.
5,745,902 - Method and system for accessing a file using file names having different file name formats. Filed for on July 6, 1992. Reading the abstract of this one, you'd have to allow renaming of just the name and preserving the extention for the purposes of keeping track of the filetype. Abstract explicitly mentions the use of a B-tree (Limits the scope of what they're claiming- you can possibly sidestep things by using red-black, AVL, etc...). They don't appear to have troubled this application with a possible prior art release, but unless you're doing the exact same thing for handling renames, etc. I don't think you're impacted by this one.
5,758,352 - Common name space for long and short filenames. Filed on September 5, 1996. A cursory reading of the Patent filing made by Microsoft leads one to believe that this is a re-application of the 5,579,517 Patent. While I'm not an IP lawyer, they appear to be claiming the same basic things in both documents. If this, in fact, the case, the 5,579,517 Patent's invalidation would likely invalidate this one. You would probably run afoul of this Patent if you attempted to implement a VFAT style filesystem.
6,286,013 - Method and system for providing a common name space for long and short file names in an operating system. Filed on January 28, 1997. This one is an EXPLICIT Patent-style description of how Windows 95/98/Me handles long filenames on an x86-32 platform. Cute. The applicablity of this Patent to anything other than an exact clone of Windows 95/98/Me is doubtful at best. They explicitly mention things like BIOS interrupts and x86 register names in their claims. Better yet, the preferred implementation was deployed to the World at large in Windows 95- TWO YEARS PRIOR to the filing date.
You should consult a Patent attorney before making any decisions regarding this request for royalties from Microsoft. However, having said this, I'd feel fairly comfortable about the situation overall based on the observations made above.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
In the case of FLASH in particular, it is also the way that the system "wear-levels" the medium since flash has a life-cycle for each bit. I know the life-cycle is getting far longer than most people are likely to run up against (100,000+ cycles) but the other part is that flash does not just flop bits one at a time back and forth between 1 and 0 - it does this in blocks at a time - writing all 1s to a block to erase it. This needs to be managed somehow - and it needs to be done in a manner that can survive power and "finger" problems (with removeable cards) - and that's what JFFS is all about.
Suggesting TAR as a file system for something like FLASH is crazy!
Been there, done that, paid for the T-shirt
and didn't get it
While flash is random access and doesn't have a physical seek latency, it is indeed a block device. On reads this isn't evident, but on writes it is. You can only overwrite whole blocks at a time. This is why it actually does make some sense to use traditional file systems on flash devices.
The enemies of Democracy are
Nope. NTFS is a metadata file system. Read as "Extended Attributes". The data is an attribute on the file pointer, as are the SACLS, DACLS, location, etc. It has much much much more in common with HPFS (guess why) than FAT.
Of course it also has multiple file tables as well. In short, quite different from FAT, for better or worse.
"My God, this must be a truly remarkable corn chip, to be so widely and confidently touted."
SCP's QDOS was written in Feb/March 1980 and released as 86-DOS in late 1980. While the idea of using a FAT was based on BillG's Disk Basic, the specific implementation of FAT-12 was Tim Patterson's work while at SCP. Also recall that 86-DOS was written in such a way that it was very easy to port CP/M programs - i.e. similar data structures for the file control blocks.
PC-DOS 1.0 was a re-warmed 86-DOS 1.14
A Shadeless room is a brighter room.
Maybe in theory, but it's not like the patent guys have time to verify complete documentation by sitting down and re-implementing each and every application using only the applicant's docs. Considering the way the patent system has been bent, folded, spindled, and mutilated in recent years (e.g., Amazon's one-click, Netflix's business model), less-than-complete disclosure starts to look like the least of the patent office's worries.
No, NTFS is a rip off of the HPFS so how could they ever patent it. They stole it from IBM's OS/2. Well Actually IBM gave it to them when they signed a technology share agreement so OS/2 could run windows 3.1/3.11 programs better. The agreement, being two ways, allowed Microsoft to rip off the gui look and feel (Windows 95/98/NT4 and enhanced versions on ME/2000/XP) and to rip off the file system for use in NT/2000/XP. MS wanted that gui for years, but the company (visicorp) hated MS and only licensed it to IBM, who bought the rights and subsequently made that stupid deal with MS. Its too bad MS did not just steal the whole OS/2 since it was more stable and all.
Ok, I'll bite. IMHO, NTFS is about as different from FAT as any Real file system.
FAT is very simplistic, there's essentially two structures. One is the File Allocation Table, which keeps track of which blocks are used in what way (e.g. part of a file, last block in a file, bad block, free block). Then there are the directories, which are just arrays of inodes, which also contain the file names. The inode points to the first block, the FAT tells which blocks follow. There are no permissions, hard links, symlinks, file types (other than regular vs. directory). The FAT and root directory are stored at the beginning of the volume.
Now to NTFS. (Disclaimer: NTFS is complex and I don't claim to fully understand it.) NTFS Has a Master File Table, which has inodes for every file on the volume (which are seperate from filenames, like on Unix file systems). NTFS supports hard links, symlins, attributes, permissions (based on Access Control Lists), and sparse files. File names are looked up in b-trees rather than sequential lists. Instead of listing every single block occupied by a file, it uses start, length pairs (AKA extents). NTFS uses journaling and supports transparent compression and encryption. Several structures are stored in the middle of the volume to minimize seek times.
Compare this to traditional Unix file systems (UFS, FFS, ext2). There's an inode table at the beginning of the volume. Inodes encode ownership, permissions (based on owner and group), a few attributes (e.g. setid bits), often part of the block list or the content of the file. Directories are sequential lists of (inode number, file name) pairs. Hard links and symlinks are supported, as are special files like devices and FIFOs. No extended attributes, no B-trees, no ACLs, no compression, no encryption, no journaling. (although many/all of these have been added at one point or another to ext2 and FFS, sometimes preserving compatibility). Important structures are replicated in various parts of the volume to enhance speed and reliability.
As you can see, NTFS is a very advanced filesystem, supporting many features that Linux filesystems are now beginning to have. FAT is hardly any more advanced than the very minimum required to store and retrieve data. Unix filesystems are somewhere in between, supporting features important to Unix systems such as permissions and device nodes, while at the same time keeping it simple. Personally, I think a the traditional Unix filesystems are much closer to FAT than NTFS is.
Please correct me if I got my facts wrong.
Thank you for your excellent reading. This should definitely be modded up. However, I'd like to add a couple of comments.
First, by your reading, it seems that only VFAT is affected. This is bad, but not as bad as it could be.
Second, some other people have posted that the license applies only to embedded devices. This has nothing to do with the infringing or noninfringing nature of Linux. All this means is that the only group Microsoft has offered to license to *legally* use long filenames on FAT is the embedded folks. This means that there is currently no option (if indeed the VFAT kernel module infringes, as it appears to do) for Linux folks to have uninfringing use. There is no requirement for Microsoft to provide such a licensing option, and they may sue for damages regardless of whether or not they provide such an option.
Third, my reading is that your argument about the patents being invalid due to prior art is incorrect. The relevant section is USC 35, Part II, Chapter 10, Section 205. The relevant clauses are (a) and (b). (a) does not apply because it only relates to prior art as produced by others. (b) does not apply because it refers to *public* use or sale -- not a couple of MSDN members or whoever got to play with Chicago betas. Windows 95 was released in August, 1995. This is less than a year before the patent application in April, 1996.
May we never see th
Of course this is stupid, bad, mean, blah blah blah. You guys have already covered that. What's interesting to me though is that Microsoft needs device makers to make devices that favor (or atleast are compatible with) windows. iPOD (used to) prefer Macs, and so someone in love with iPods would probably prefer a mac. If Microsoft discourages manufacturers from making devices compatible with windows, they will end up hurting their popularity (duh.)
no comment
The purpose of the DMCA is for situations like Adobe's ebook, where if someone cracks the encryption they'd get free ebooks. In that situation the DMCA is a Good Thing.
Nonsense.
Copying, distributing, etc. was protected by copyright prior to the DMCA and still is. The only thing DMCA changes in the equation, is the addition of extra punishment. Just like a robbery vs a robbery with a gun -- using the gun is a special condition that allows additional punishment for the illegal act of robbery even if everything else is exactly the same. The DMCA is nothing more than a club to provide additional leverage (via punishment) for copyright violations.
sdb
Kind of a moot point. The patents MS lists in the notice are related to FAT 32, which is easily the most widely used implemetation of FAT now. FAT 16 only supports up to 2GB, whereas FAT 32 supports 32GB. Anyone who sets up a FAT partition on a dual-boot system as a common file storage area will be using FAT 32.
Those patents were granted in the mid-90's, and short of invalidating them via prior art claims, they won't expire for another ten years or so.
I'm positive that HFS is read-write supported by linux, however I believe that HFS+ support is still experimental.
The FAT file system format was never patentable to begin with, since there was nothing particularly novel about it when it was created. What's more, it has been in use for more than 20 years (the lifetime of a patent) and nothing about it was patented within a year of its implementation and release to the public. So, Microsoft has no rights here. Its claims to the contrary are absurd.
You obviously don't know anything about modern Unix systems. Directories have not been sequential lists in a LONG time. Get your head out of the sand. B-trees and lots of other data structures have been used before Mr Bill started working on DOS!
To be honest I think the abilities of NTFS and current Unix files systems are about equal.
And I would very much like to know how to convince stupid Windows to make one of those "symbolic links". I have NEVER seen this work (by "work" I mean that when I call open() and read, I get the contents of the pointed-to file, not gibberish!)
Did anyone read the original link?
They are offering a license for 25 cents per unit with a MAXIMUM for big companies of 250K.
Without getting into the merits of the claims themselves, as far as licensing goes, that's a very reasonable fee.
As you can see, NTFS is a very advanced filesystem, supporting many features that Linux filesystems are now beginning to have.
You are confusing feature bloat with being advanced. NTFS is a feature-bloated file system, but none of the features they crammed into that file system are anything new, and many of them will never make it into mainstream UNIX file systems because they are just not a good engineering tradeoff.
Compare this to traditional Unix file systems (UFS, FFS, ext2).
Your comments imply an incorrect timeline. By the time NTFS came out, there were already several UNIX file systems with a comparable feature set. Furthermore, a number of key NTFS features existed in name only for several years, until Microsoft finally got around to implementing them.
Uhhh, neither is FAT.
FAT has fixed size directory indexes. If you have half a dozen files in a directory, you are discarding most of the directory index. If you make the directory index small then you can't store lots of files in a single directory. It's a no-win tradeoff. A space efficient filesystem would use dynamically resizable directory indexes.
The FAT itself is a bitmap (one FAT entry for every single block) with each entry referencing the next entry (like a linked list). You find the first block of the file from the directory index. Imagine how inefficient this is when the file has contiguous blocks. Why not use extents? That would greatly reduce the space requirements for the FAT.
The original FAT16 limited you to only 65536 possible block numbers. If you have a 512MB USB key then that means every block is 8kB. So on average you waste 4kB per file; 1000s of files means many megabytes of wasted space. Another glaring example of FAT inefficiency. A space efficient filesystem would offer variable sized blocks.
For FAT to perform efficiently you must load the entire FAT into memory (otherwise traversing the list of blocks is a nightmare of head seeks). This makes it vulnerable to files being corrupted or lost if there is sudden power failure or the disk is removed. The "saving grace" is that the FAT is protected because it never had the chance to be flushed out of RAM, so the filesystem is at least consistent. Whether this behaviour is good or bad seems to be a matter of debate; my opinion is that the data is more important than the damn filesystem and FAT fails in that regard.
The only thing FAT has going for it is incredible simplicity which made sense on the woefully underpowered and underfeatured IBM PC of 1980. But in terms of efficiency it is exactly the same as many other bitmap-based filesystems. FAT was also heavily optimised for 320kB (that's not a typo) floppy disks because the FAT would fit into a single 512 byte sector. It makes no sense in a modern world with gigabyte removable media.
These USB keys should be using something clever like CRAMFS but with journalling and "balanced writes" (each block gets roughly equal write time) to preserve the life of the key.
I agree with your point but feel to correct yuo on one thing:
The cameras don't talk to each other, so it won't matter if the camera I buy next year doesn't speak FAT.
Oh really? You've never moved a memcard from one camera to another? You don't enjoy the convenience of tearing an SD Card out of its package and immediately jamming it into your camera, without reformating it first? (Which would erase any data already on the card)
I use Compact Flash cards as a substitute for disks - they are more resiliant and have more space. I usually format them to ext2 and guess what, one day my friend snapped picutures with his camera and filled his CF and I lended him my, formatted as ext2, and the camera had no problem as it formatted it to FAT itself.
So I doubt that compability would be an issue for new media, only if you need to save something allready on CF.
Stick a USB pen drive into a Windows XP machine and it loads the drivers and gives it a drive letter.
Compare this to traditional Unix file systems... ...no ACLs
Just FYI Solaris has had UFS ACLs since 2.5.1 (many, many years ago). Extended attributes (depending on what you mean by that) came along in UFS+. Now look at modern commercial UNIX filsystems such as SAM-FS, VxFS etc.
Oh? My fully-functional 83GB FAT32 partition makes me seriously doubt that.
LOAD "SIG",8,1
Might be useful to some:
l ic /www/doc/abstracts/dos-fs.html
l ished/do s-fs.ps
Alessandro Forin used to work for CMU on the Mach kernel and presented at Usenix in 1994 a new file system that used FAT as its storage, and had been extended to support extended file names.
He later joined Microsoft.
The abstract:
http://www-2.cs.cmu.edu/afs/cs/project/mach/pub
The paper:
ftp://ftp.cs.cmu.edu/project/mach/doc/pub
A use of the Invention outside of the Inventor or his Employer constitutes an offer for sale or gift thereof, regardless of the disclosure conditions the party recieving the gift or sale since they are not parties to the Company by way of the agreement (These agreements are SPECIFIC about this sort of thing, by the way...).
It's kind of moot anyway. The Patent in question was a continuation (something I missed- it's why you're supposed to consult a Patent attorney, BTW...) and therefore had a prior art start date of April 24, 1993. However, the Rock Ridge RRIP specification for the ISO-9660 filesystem describes a largely identical (by the reading of Microsoft's actual Patent claims- this one's nicely broad) scheme that implements short (i.e. 8.3) filenames in the same database as long filenames (i.e. POSIX 256 character names...) for the purposes of transparently supporting long filenames on systems that would and providing the regluar means for accessing the short ones on systems that don't understand the extentions. While it remains to be determined that this is, in fact, Prior Art, it's likely to be so and it was initially published by the Rock Ridge group in 1991, some 1-2 years prior to the filing by Microsoft on all of that.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas