Universal File System

[Candy]

i thought the universal file system was supposed to be simple and basic and now we're talking about UTF8 and different languages. In my opinion choose only english in the beginning even with UTF8 if so needed and add other languages later version 1.1 or so.

UTF8 is identical to ASCII, as far as ASCII goes. For all purposes, if you only use ASCII, it'll just work.

If you use more, it'll work the same, but your OS might not recognise them. Ignore it then.

The simple&basic part was about underlying algorithms etc. We're not going to use fragmentation or B+trees or such.

[Brendan]

Hi,

That's pretty much limiting enough for it in its current form to be unusable. However, the driver for it is clear and similar to what we're trying to do, so I'm hereby volunteering to make a linux driver for our FS. Makes testing your OS a lot easier, when you have a simple filesystem you can write to (esp. if it isn't patented from here to japan and back). Also, it makes for practice for my own fs in linux (which'll be quite a lot harder to make).

Wow - cool .

Then there's the point of a driver for Windows and one for MacOS X. I might be able to do the windows one in some time, but I can't make a MacOS driver. The Linux one will be PD, the Windows one as far as I can make it also, I would prefer the MacOS one to be PD as well. That way the filesystem is entirely open and free in any form of meaning so people can use it just as easy as FAT (sometimes easier). I'd also prefer if somebody wrote an OS-independant version in multiple languages (I'll help translate to some), among which at least pure C and assembly, since these are used by quite some people doing OSdev that are not specifically going to try to support it.

Unfortunately, I lack any Apple hardware and have no real experience with MacOS or Windows programming (unless "Visual BASIC for Applications" counts).

IMHO OS independant file system drivers are like OS independant device drivers (difficult to do in practice). With your Linux driver (which I assume would be written in C), my assembly language boot loader (which will at least include a function to load any file from the file system, and could include a lot more), the formal specification and possibly other "support" (some email addresses, an FAQ, maybe a wiki page, etc), I think there'll be enough resources for other OS developers to follow in the short term.

As a final point, we'll need a public website that carries out the message and content, publication on technical magazines (write to linux magazine, slashdot etc) and we could use some active approaching of flashdisk device manufacturers and flashdisk manufacturers for support of the file system.

I can host it on my server as a temporary measure, but something like Sourceforge might be better. For publicity, I think we should wait until there's a good reference implementation of it (a nice Linux driver for e.g. ) before publicizing it through news sites, etc, and then wait until there's a Windows driver for it before approaching hardware manufacturers. That way we'd be able to tell manufacturers that full Windows support is already possible (which would be a major consideration for them).

I've noticed the short name SFS is still free. It could be used for StarFS, but I think we'll stick with the long one, so it could be used for this one. Two suggestions: Slim (as opposed to FAT) or SimpleFS (or just SFS).

I like "SimpleFS" (people can abbreviate it to "SFS" if they want). To be honest I was trying to come up with a clever acronym ("SPIFFY" or something) but I don't seem to be clever enough to think of anything good. ::)

Isn't that more a matter of the user interface anyway ?

I agree - how an OS handles UTF8 isn't the file system's problem, and most OSs have probably already solved these problems in their own way (they would've had similar problems with some CD-ROM formats and possibly their own native file systems).


@DF: Is there any online documentation for Minix V1FS (in English)? I tried google and came up with some German sites and single and double flange butterfly valves used on concrete mixing plants.


Cheers,

Brendan

[Slasher]

I'll gladly implement this as a subsystem in my os as I'm yet to do the file system in mine.

Once a clear specification is drawn out,I'll get to coding!!

[DennisCGc]

I have nothing special to add.. but I'm a bit concerned with the fragmentation part (no fragmentation?!). We can't use a cluster table, as is used in FAT.

If no there's no support for fragmentation then I'll have another suggestion. Searching for free sectors takes a bit more time when you are only searching through the index area. Maybe a bitmap area would speed things up?

But anyway, I think it's a good idea to create this FS. It allows a simpler implementation than FAT does. The help I can give is a hosting place (can give it a max. of 100 GiB traffic per month? Might be more or less) Or my personal server can serve as well. And I'll implement it in my OS.

As for the name, some suggestions: UFFS, PDFS.

DennisCGc.

[Colonel Kernel]

Does anyone have a sense of how broad the FAT patent is? Does it cover concepts that are applicable to all filesystems (or perhaps concepts that people have been discussing for this universal file system)?

I'm concerned about the legal implications... I'm guessing that many people participating in this discussion are already somewhat familiar with the internal workings of FAT. Isn't this dangerous? Isn't it a better idea to get developers who have never seen the internals of FAT before to work on this?

Just a thought...

BTW, as far as names go, I like SlimFS.

[Dex4u]

As far as i am aware, it mostly to do with the way, fat deals with LFN.

[Candy]

Does anyone have a sense of how broad the FAT patent is? Does it cover concepts that are applicable to all filesystems (or perhaps concepts that people have been discussing for this universal file system)?

I'm concerned about the legal implications... I'm guessing that many people participating in this discussion are already somewhat familiar with the internal workings of FAT. Isn't this dangerous? Isn't it a better idea to get developers who have never seen the internals of FAT before to work on this?

That would be very hard to get working. Find a team of people that like file system design in their free time (or at all) and that have never seen FAT or the concepts of FAT.

Oppose that with people who have seen FAT and a bunch of other file systems.

Which team would you prefer? If you've seen enough, you can consider what would be optimal, even though it is impossible to reach.

[Kemp]

The MS site says the FAT patents cover

* U.S. Patent #5,579,517
* U.S. Patent #5,758,352
* U.S. Patent #6,286,013

The first is long filenames and short filenames having the same namespace and being compatible with short-only systems (though that patent in itself is stupidly general in regards to scope). The second appears to be a copy of the first patent ??? And the third is also the same. Talk about redundancy...

Though the page in FAT licensing and patents does refer to other patents that they are waiting on, which may be the ones referred to in the article.

[Candy]

* U.S. Patent #5,579,517

Summary:

You cannot implement an operating system for a computer with processor that uses long file names split into more than one directory entry.

*
U.S. Patent #5,758,352

Summary:

You cannot implement an operating system, application program, hardware system or storage medium which uses multiple directory entries for a single file name (same as last, but wider).

* U.S. Patent #6,286,013

Jeez... this one's especially badly written, example:

2. The application program interface of claim 1, wherein the function is selected from a group, comprising 5704h, 5705h, 5706h, 5707h, 7139h, 713Ah, 713Bh, 7141h, 7143h, 7147h, 714Eh, 714Fh, 7156h, 7160h, 716Ch, 71A0h, 71A1h, 71A6h and 71A7h.
...
5. The method of claim 4, wherein the operating system supports a plurality of numbered software interrupts and wherein the second function is called by generating software interrupt number 21 in hexadecimal notation.

6. The method of claim 5, wherein the operating system supports an AX register and the second function is called when a value of 7139 in hexadecimal notation is disposed in the AX register.
...

Summary:

You can't use an API that allows you access to long file names on an operating system only supporting 8.3 filenames. There's a complete list of all things you can't do.

You can't implement anything using two functions, one for long and one for short filenames, the first calling the second for the short filename. You can't let the second call the first either, but that only in specific cases (searching is listed).

You can't provide or use an API allowing you to use those two functions either.



Summary of all:
You can't use long filenames or you'll be sued. You can't even assume any aspect of them.

For the rest, FAT is ok. Assuming there aren't anymore patents, which I doubt. For me, screw microsoft, I'm still going to implement it (not US resident, no aspiration of ever going there). For this project, I'm most certainly going to advocate not using FAT or NTFS at all.

As far as i am aware, it mostly to do with the way, fat deals with LFN.

That's 100% correct. For these patents, at least :S... Anybody feel like checking out the other millions if they might apply?

[Brendan]

Hi,

The second appears to be a copy of the first patent ??? And the third is also the same. Talk about redundancy...

Unfortunately this may be "common business practice". The idea is that one patent expires in 15 years, so every 5 years you apply for another patent in an attempt to lock your competitors out indefinately (or for as long as your lawyers can manage). Luckily, to do this you usually need to modify the existing stuff in some way and patent the modification (but "usually" might not apply to Microsoft).

What we need is a file system that is designed for exchanging information between computer systems that can't be restricted by lawyers (now or in the future), and that is not limited to where you live or what language you use.

Summary of all:
You can't use long filenames or you'll be sued. You can't even assume any aspect of them.

For the rest, FAT is ok. Assuming there aren't anymore patents, which I doubt. For me, screw microsoft, I'm still going to implement it (not US resident, no aspiration of ever going there). For this project, I'm most certainly going to advocate not using FAT or NTFS at all.

I'm going to follow the patent and implement support for "8.3 ASCII" file names in FAT file systems only. Every time the user tries to store a file on a FAT file system I'm going to have a dialog box pop up telling them that the file name needs to be mangled due to Microsoft patents, which will include a button they can press to convert the FAT file system into an SFS file system. I reserve the right to forget to remove this warning when the patents expire...

Unfortunately, I'm an Australian resident (Australian politicians seem to lack the courage possessed by their European counterparts).


Cheers,

Brendan

[beyondsociety]

I read the link on the patents and I didnt see any mention of the BPB (BIOS Paramter Block). Can I still use the BPB to find the sector/track values so that my os can recognize the floppy drive?

[Candy]

I read the link on the patents and I didnt see any mention of the BPB (BIOS Paramter Block). Can I still use the BPB to find the sector/track values so that my os can recognize the floppy drive?

According to these patents, you can use the BPB, you can use the FAT table itself, you can use the directory entries, but you cannot use more than one directory entry for one file, if the second and further on are going to be used for a long file name for the short file.

Hmmm.... what if you don't store the short file name? Is that possible? That would circumvent the patent.

[RetainSoftware]

@brendan
(S)imple (P)atentless (I)ntegratable (F)ile (F)ormat for (Y)ou

@candy

According to these patents, you can use the BPB, you can use the FAT table itself, you can use the directory entries, but you cannot use more than one directory entry for one file, if the second and further on are going to be used for a long file name for the short file.

Hmmm.... what if you don't store the short file name? Is that possible? That would circumvent the patent.

my thoughts exactly. what if you store an index number wich is used for a dbase with filenames then i don't store long filenames nor short names in the directory entries. or remove directories all together ;D

[JoeKayzA]

Hmmm.... what if you don't store the short file name? Is that possible? That would circumvent the patent.

... but render the filesystem incompatible with current vfat drivers (AFAICS). So you are still creating a 'new' fs and have to provide adapted filesystem drivers....

[Candy]

Hmmm.... what if you don't store the short file name? Is that possible? That would circumvent the patent.

... but render the filesystem incompatible with current vfat drivers (AFAICS). So you are still creating a 'new' fs and have to provide adapted filesystem drivers....

Would be a bad thing. I was thinking more of just forgetting the small file name entry. I think however, that it still has to be used for the filesize etc, so that it isn't possible to ignore it.

I think that if you ignore the short filename that you'd be ok... but IANAL of course.