OSDev.org

oh, and btw, it all depends on how those "-" are encoded. say the former fig is actually represented by:

then it becomes clear that room beyond file 2 (that is, blocks 20..29) is actually free for something else, since from the size of index[1] (which owns those blocks), they're unused.

To keep things clean, when such a "llama-with-screws" driver will detect room that needs to become "free", it just locates the previous file entry (not necessarily [i-1], thus), and extends the "eblk" value so that it now covers the "free" space (let's say that's how file 1 has "---" after it).

The "camel-with-stick" driver that wants to "shrink" a file just updates the "byte size" of the file, and both camels and llamas are kept happy.
Similarily, the "camel-with-stick" that wants to make the file deleted just tags it as "deleted". both llama or L2 driver will be happy and recover the space of the deleted file if they feel like.

Just wanted to let everyone know that there is a File system already called SFS. Think we should use UFS(Universal File System) like in the very first post of this topic.

You might just offend those that invented Unix, they kind of claimed UFS for "Unix File System".

Forgot about that ;D Well we still need a different name.

VSFS (Very Simple File System)?

This is a bit late and I hope it's still of some use.

The incremental counter I was talking about is part of the super block.

Something like this:


Anytime the superblock is modified, block with the older count is used (with count updated).

Therefore if there was a power failure etc in the middle of writing the super block, we still have an older version.

Brendan, this looks like a nice, easy-to-implement file system. Just a quick question, though. Why does the draft spec say that the superblock has 64 bytes of space reserved for a partition table? I though the only boot sector with a partition table is the MBR, and the MBR has no file system, it just loads the active partition.

Also, why not require the index area to be a multiple of the block size? I think it would make coding a driver easier, since the index is always an integer number of sectors on the disk.

Hi,



Ah - sorry I misunderstood

Still, all file data can be recovered without using the super-block at all, so a second super-block doesn't seem too necessary.



Reserving space for a partition table doesn't cost anything (nothing lost) and allows for non-standard arrangements.

For example, on a hard disk partitions usually start and end on cylinder boundaries. This leaves the entire first cylinder wasted due to the MBR. Boot managers typically take advantage of this space for their own use - it would be possible for a boot manager to have an SFS file system hidden in that first cylinder where it won't be messed with by the OS.

It's also possible to have a hard disk without partitions (where then entire hard disk is like a huge floppy). In this case it'd be good to have a dummy partition table to tell other OSs that the entire disk is in use.

I agree that there isn't a good reason for it, it's just that there's no reason not to.



The idea here is that when a new index area entry is being created a very simple driver could add 64 to the index area size and then do "end_of_disk - new_index_area_size" to find where to store the next index area entry. In this case the very simple driver wouldn't need to check any existing index area entries to see if they are currently unused.

A better/more complex driver would check if there's any unused index area entry before creating a new one.

If the index area size was a multiple of the block size it'd make a very simple driver a little more complex and a complex driver a little simpler, but this isn't what I want to do (I'd rather make a very simple driver a little simpler, even if it does make a complex driver a little more complex).


Cheers,

Brendan

Micro$oft are eejits, who would do such a thing???

Patent the FAT file system >:(

What is the state of the file system?

can we try to implement it now or wait for a finished spec?

Isn't the ISO 9660 FS (the one used in CDs/DVDs) suitable for such a task? I apologize if it has already been suggested, but I did not have the time to read all the messages.

I'm a part-time inventor, so I'm familiar with the whole patent dealio -- and I wanted to see precisely what was meant by "Now that Microsoft has patented the FAT file system".

I know full well that FAT12 and FAT16 are well past any possible patent expirations. It turns out that the patent in question, #5,579,517 -- is actually about the specific way that long filenames are implemented in the DOS6/Windows directory structure. It's not technically about the file allocation structure at all.

So, just so long as you have some completely different way of storing your LFN's, you are safe from this patent. And the patent expires in a little under 6 and a half years.

Of course, if you are trying to implement full LFN compatibility -- so that you can read or write LFNs on a Windows formatted disk -- then the patent certainly is aimed at preventing you from doing such a thing.