FAT file system problem ... Microsoft is suing TomTom ...

formatting link

In a recent thread, it appeard that the Fat file system was a de facto standard. It seems that it is time to change this ... Is there a simple file system which is suitable for embedded use and which might gain widespread acceptance??

Cheers, Rob.

Reply to
Spam
Loading thread data ...

To avoid patents, it has to be over 20 years old, or based on technology over 20 years old. Possible things would be extended versions of Spectrum microdrive format, or apple II dos format extended. TRS-80 extended, maybe AmigaDOS is old enough.

ext2, ext3??

rasierfs??

Ok?

cheers jacko

Reply to
Jacko

I source for TRS-80 available somewhere?

Hul

Jacko wrote:

Reply to
dbr

CP/M predates DOS and, if I heard correctly, the guy writing DOS before it was purchased for a few tens of thousands of dollars by Bill based it on CP/M's system (from an outsider's point of view, not necessarily the code itself.) I used CP/M, which included a very, very similar looking prefix area that DOS implemented as part of its .COM structure (before the .EXE format arrived in version 2, which also supported it, too.) That area was called the Program Segment Prefix under DOS, but was almost identical (to the byte, it seemed) to CP/M's structure.

I no longer remember much about the file support structures under CP/M, but have a bit of a hard time accepting the idea that it doesn't represent substantial prior art. And even that has been well predated by file systems supported on larger machines (prior to the existence of the early microcontrollers such as the 8080.) The needs are quite similar across the board and a great deal of prior art exists going back many, many years with a lot of similarities.

Must be any number of suitable formats only slightly different from each other. For flash file or EEPROM based systems, wear leveling is likely important, though. That a newer problem with newer solutions. Even there, I suspect there are non-proprietary systems available.

Jon

Reply to
Jon Kirwan

I thought it was the 8.3 system that was the subject of the legal action?

I'm probably wrong... didn't pay much attention....

Steve

--

formatting link

Reply to
Steve at fivetrees

There were several DOSes for the TRS-80. The (varied) disk formats are well documented in various places but the "source" you're after doesn't exist in any usable form - all the original file-handling was written in Z80 assembler. There are utilities that will read/write files to/from emulator disk formats, though I'm not aware if the source for them is available.

In any case, it's probably worthless. TRS-80 disks were only ever a few hundred KB in size, and I've little doubt that the disk formats are incapable of supporting larger formats.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

which in turn was based on DEC RT-11, though it ditched the radix-50 encoding of filenames.

I implemented the CPM filesystem in C, and still have the code, though I no longer have the code of my similar RT-11 filesystem.

I don't think the prior art in CP/M's filesystem would be of much use in implementing a ubiquitous filesystem standard today. The free space allocation and directory formats were minimal and inefficient, and there was no directory hierarchy.

In any case, I don't agree that an old filesystem must be replicated to avoid patent claims. There are many good modern filesystems that have been around for ten years and haven't been challenged; and that fact alone would greatly weaken a challenger's position.

The difficulty isn't coming up with a format, it's building ubiquitous free implementations.

Clifford Heath.

Reply to
Clifford Heath

Thanks, Cliff.

Jon

Reply to
Jon Kirwan

Er, no, that's easy - the difficulty is getting it to just work when inserted into a windoze box.

There are for example ext2 drivers for windows, but they won't be on most people's PCs, so windows will see the volume as unformatted, and rather than inviting you to install some sort of driver, will offer to format it as fat-whatever for you.

Here's my idea:

Create an open standard for a sort of bi-modal file system. To a vanilla windows box, it will look like an old-style fat filesystem (which MS lost claims on) containing one file - which is an installer for the true file system driver, and if necessary, a second dummy file reserving the rest of the space.

Once the true filesystem driver is installed on windows (or on any sensible operating system or embedded device which has it built-in), then you see a modern, unencumbered file system giving you practical access to the entire volume.

I don't think the engineering to do this would be particularly hard - a little cleverness, some peer review of the concept, reference implementations for windows, linux, and a few RTOS's.

What is needed is a sort of universal by-in from all of the major players except microsoft. There needs to be one-industry standard open solution that everyone else is supporting natively, and that has this little installer trick to impose it on microsoft by making it available to their users.

What won't work is to have half a dozen different solutions, each with it's own file system driver that requires installation. It's got to be one solution, well engineered, that everyone is using.

Perhaps some of the system, device, and card manufacturers who stand to benefit could get together, announce a design contest and form a jury to judge the entries. Prize should be about 2 years worth of developer salary.

Reply to
cs_posting

Then there's the problem that you can't use ext2 on many statically linked embedded systems, because it has the GPL license. Ext2, and many modern file systems, are also a bit too complex for smaller embedded systems.

FAT works because of several factors. It's everywhere; it's small and simple to implement if you want to roll your own; there is wide availability of code that implements it with a variety of license restrictions if you don't. There is no other file system standard that is this ubiquitous or better suited for simple file interchange.

Reply to
Darin Johnson

You are mixing up implementation and specification here. The ext2 format has no licences, patents, copyrights or anything else limiting it (there may be a trademark on the name, I suppose). So you can freely implement it as you want in any language, for any system, and with any license.

The implementation in Linux, on the other hand, is under the GPL, and can thus only be used directly with GPL'ed code.

That might be true - I don't know enough of the details.

Reply to
David Brown

I may be wrong, but I believe you can use GPL licensed systems. You can't use GPLd code without making your adjustments available to all. But you can freely write new code to access an ext2 (or ext3, etc.) file system.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

ple

Yes, you are wrong. The 8.3 file system is either too old (I am pretty sure this is the case) or as others have said, has not been enforced and so may not be enforceable. The main thing that they get people on are the extensions MS added for long file name support. I think one of the earlier posts of a link listed some of the various patents that are claimed to be infringed.

I am pretty sure that there are literally hundreds of products that use the old 8.3 file names and the companies have never been sued.

Rick

Reply to
rickman

Careful with your attributions - I said that.

That's what ubiquitous means ;-)

That's been done, but yes, it's a good idea. The problem is if the user's not an admin, you can't install the filesystem driver.

Reply to
Clifford Heath

That's what I thought. The companies that I've noticed get into trouble have been making custom adaptations of the Busybox shell/utilities replacement program, and not publishing their changes.

Mel.

Reply to
Mel

To be precise: you *can* do with GPLed code whatever you want. But: if you pass the results (any derived work) to any third party, you need to give them (and only them) the rights the GPL offered to you, i.e. you can't block them from accessing the source code if they wish to have a look at it.

Reply to
Heike C. Zimmerer

That's not very precise :-)

If you pass a GPL-derived program (i.e., a program which is under the GPL, or which links statically or dynamically to GPL'ed code) to someone else in either binary or source-code form, you need to offer them access to the source code for the entire program under the GPL. You don't need to offer it to third-parties, but you cannot restrict legitimate parties (i.e., those you gave or sold the program to) from passing it on to anyone they want under the GPL.

The rights under the GPL are not just the right to look at the code, but the right to modify it and use it as you want, and to distribute it under the GPL. You may also have the right to replace the original binary with your own version (that's a key difference between GPL v. 2 and GPL v. 3).

The point of this is that if you buy an embedded system with a modified version of BusyBox, you can ask the supplier for the source code, pass that on to me, and I can modify it and use it in my own embedded systems that I sell. Of course, I too have to give my modifications to any customer who asks.

Reply to
David Brown

He committed the simple sin of deleting attributions. Don't do that. You can detect it from the wrong number of '>' marks.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

That's not very accurate.

If you are required by the GPL to make a source code offer, then that offer is required to be open to third parties, not just to your customers.

However the whole line of argument is not too relevant as has already been pointed out - the GPL applies to an implementation of an ext2 driver, not to all possible implementations of it. For example the "IFS Drives" Ext2 driver for windows calls itself "Freeware" - it is not under GPL.

But the real problem is not the suitability of ext2 or some other file system, the real problem iis that windows without an appropriate driver for a given filesystem will consider the media unformed and helpfully offer to fix that for you. That's the problem I was trying to solve.

Reply to
cs_posting

Problem... or maybe solution.

It can be argued that the if the user has not been authorized by an admin to use a class of removable media, then it's a great thing if they can't access it.

In other words, if the admins decide you should be able to use your USB ports, they'll install the driver (because there's only one, that everybody but MS endorses). If they decide you shouldn't, then not having the driver, while hardly an effective security measure (as long as FAT media still exist) is something of nuisance obstacle to doing things you weren't authorized to do anyway.

Reply to
cs_posting

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.