Microsoft's exFAT Is Still Cr@p On Linux

FWIW: Many cameras also impose an 80-minute limit on a single video file.

I am not sure if there is work being done in the Linux world to create a special file system for storing data on consumer electronic devices. With all the different file systems supported on Linux, there ought to be one. The community just can't keep MS & Apple controlling that area. With all the threats to security & privacy, the community must have one.

A number of CE manufacturers are already using Android/Linux, it makes sense to use a file system that is native to the OS. Since the majority of people are still using Windows on desktops/laptops, the file system needs a good driver not only for Linux, but also for both Windows, & Apple. The driver should also be included on the CD that comes with such devices.

I don't think it is too late.

All that's (really) necessary in Linux is to be able to read, and/or delete exFAT partitions... DV cameras can connect as a block device & be read that way. You can handle partition creation and file manipulation on the device itself. Plus, many of these kinds of devices (like phones) have a software layer that allows them to emulate a USB mass storage device.

I'm guessing M$ uses exFAT in their telephone OS... Which is why it's been said that SD cards become "unreadable" in other devices after WP7 has set them up. ExFAT is also, apparently, used for OEMs to create "hidden" recovery partitions on HDs & SSDs. Point is, when gParted (updated) is used, you can identify & delete exFAT partitions. I think you may even be able to read them too.

PS: @fetoosh:



BTRFS,... but it's not quite ready for prime time yet,... since there are fatal errors on devices that don't properly support flushing.

@JaseP

Are you saying we really don't need to be off the MS treadmill?

What about CE Manufacturers who want to use Android/Linux on their DV cameras? TVs? etc.? Are you OK with all that?

[Edited] @JaseP:

I saw your PS after I posted this comment.

I'm way OK with Android based cameras, etc. But I don't believe Android supports exFAT,... I could be wrong. I believe Android supports FAT32 long filenames & Linux partition formats only... Some OEMs may include 3rd party support for NTFS and/or exFAT... I suppose, using a kernel module shim & proprietary code, to get around GPL issues.

When exFAT was announced a couple years ago it was hailed as yet more Microsoft lock-in horsecrap. Two years later, yep. In fact I railed against it my own self: http://blog.linuxtoday.com/blog/2009/08/some-answers-fr.html exFAT is just FAT64; another brain-dead uber-simple FAT filesystem. It doesn't rate a patent, or any kind of eye pee protection since it's just an extension of crappy antique FAT filesystems. The industry could have just as easily gone with a FOSS filesystem like ext2/3, and modified it so that Uncle Joe doesn't have to worry his pretty little head about permissions and ownership. Or something else, anyway there was no need for exFAT other than to guarantee a needless flow of money to Microsoft.

Khamul is right-- any Linux user who wants to use modern multimedia devices is stuck with the Tuxera driver. exFAT is useless and stupid, and another example of the unholy influence MS still exerts on the whole tech industry. I predict that someday soon Ballmer is going to wake up and go "We don't need to produce and sell actual products--our global protection racket is doing just fine."

gparted can detect exFAT. That is all. It cannot read it. There is no FOSS option for exFAT.

Quoting: I'm way OK with Android based cameras, etc. But I don't believe Android supports exFAT

My point was about not being solely dependent on MS proprietary file systems and you seem to be OK with being dependent on MS exFAT since we can read access it. The whole point is about a file system for CE devices that can be read & written to on Linux without being encumbered by any patents, especially MS ones.

@tuxchick

Yes indeedy, and I bet that the M$ Borg is already desperately trying to "interoperate" with Android, exFAT and all. Sheesh...

my 2c

I wouldn't be too surprised if many Android or Linux embedded devices simply licensed and used the Tuxera driver. On an expensive item like a DV camera (they're not that cheap yet), a few dollars per unit for licensing isn't that big a big deal for the mfgr, and it's not hard for the embedded developers to build it into their software build. But it keeps Linux users from interoperating with their device without having to go buy that same driver (and then muck around with trying to get it to work with their distro, possibly not such an easy task depending on how Tuxera packages this thing).

Quoting: ... without being encumbered by any patents, especially MS ones.

Well, that's the trick, isn't it?!?! OK with it?!?! No. I'm just jaded/realistic, whatever you want to call it... Work-arounds are fine by me, if they are functional. If not,... civil disobedience is always an option.

"When civil disobedience is appropriate, obedience is uncivil."

--me

Quoting: gparted can detect exFAT. That is all. It cannot read it. There is no FOSS option for exFAT.

Yet. If this goes on, I can see that code getting cleanroom-reimplemented (the same way Phoenix Technologies broke the IBM BIOS lock for Compaq by generating a comprehensive specification, then tossing it over a Chinese-wall to the coders) and the result parked on offshore servers in drop-in form (*.deb) just like the patent-laden bits of codecs are now.

Frankly, given the mess that has been Linux audio, I'm wishing that had happened to the mixdown version of OpenSoundSystem a decade-plus ago. Somebody like RedHat should have bought that outfit out and GPL'd the code, so we didn't have to put up with a blocking single-signal-source driver down at that level, and they didn't have to put up with trying to sell a toy-system OS when it came to sound.

> I can see that code getting cleanroom-reimplemented

That doesn't work with patents. Only copyright.

Quoting: That doesn't work with patents. Only copyright.

True, but offshore does. The cleanroom reimplementation walks it from Tuxera to GPL, where "cleanroom" can mean "email the spec to FUSE coders in another country where patent laws are sane".

@cr......Brazil ? I seem to recall that it was Brazil sites that hosted libdvdcss for a long time when it was difficult to get that library elsewhere.

@ridcully: <shrug> Wherever, the more the more permanent. At one time I had a tee shirt with the dvdcss algorithm screened onto it, doing my part in carrying around a piece of can't-touch-this. Is there an RFC for messaging-by-tee-shirt? Particularly an in-your-face message to somebody who's flipped their evil-bit?

> YTrue, but offshore does.

Yes, but that;'s another issue entirely. If you're offshoring to a place that doesn't recognize the patents, there's no need for a clean room implementation.

@jdixon: I can't see those offshore Debian repos knowingly accepting packages containing code which has been "given preemptive reallocation of ownership". Quite aside from the legal taint to the copyleft stance, there's the moral repugnance. Nahh, it's gotta be clean code, and code-to-spec, Phoenix-method or not, is the traditional Linux way to do that.

Addendum: I'll just say that I don't see such a reimplementation-from-spec killing Tuxera's market, either. As Khamul envisioned, I can see mfgrs licensing and using Tuxera's code, assuming it does the job right and they keep up with the kernel revisions, to avoid patent liability. The reimplemented code on the offshore servers, meanwhile, allows Linux users to get full use of the hardware they own. If my guess is right about FUSE (I've not studied it), so long as FUSE is kept up-to-date on the kernel, FUSE abstracts those ABI changes away from the userland virtual filesystem handling, leaving the exFATso devs to concentrate on getting their code to work right and maybe match MS bug-for-bug (like Samba did) if needed. Any speed loss from going through the FUSE layer is miniscule for a desktop; one more thing the mfgrs pay Tuxera for, to get kernel-level handling of exFAT in embedded systems where resources like CPU bandwidth and buffer-space are scarce. The only real loser, then, is MS, whose trollbooth on the USB datastream might bring in some money but doesn't lock out Linux.

Don't confuse clean room with work around. Clean room AND work around are needed to deal with patents, to help avoid willful infringement. But clean room, only, are necessary for dealing with copyright. Work around solutions accomplish the same end result as the patent subject matter, but do it on a manner different than described in the patent.