Who says it will only be included for compatibility?

I don't see an open source NTFS being developed any time soon, if at all,
and I'm not overly keen on all these unix file systems.

For the foreseeable future FAT is by far the best option for us. If we can
add journaling then all the better.

If we could also add optional ACL support without breaking compatibility
when we'd have a pretty good file system to move forward with.

Ged.

From: ShadowFlare [mailto:blakflare@gmail.com] 
Sent: 30 July 2009 11:06
To: ReactOS Development List
Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys

What happens if another OS makes changes, not knowing about the journal?
Does the journal need to be rebuilt (either partially or fully)?  FAT
support would mainly be for compatibility with another OS, so it is pretty
much certain that another OS would be writing files onto the file system.

Also, are there really any compelling reasons to add a ReactOS-only feature
to a file system that later will be supported mainly only for compatibility?

-ShadowFlare

On Thu, Jul 30, 2009 at 2:36 AM, Aleksey Bragin <aleksey@reactos.org> wrote:

I'll explain the FAT journalling part, it's the idea I had for quite a
while, and mainly it's just an experimental, fun idea.

So far FAT provides no consistency of neither metadata nor actual data. In
order to maintain consistency, the filesystem's integrity has to be verified
and fixed at every boot if not clean shutdown is detected.

Now, if we add a special file, let's say our driver knows its placement for
sure, and that file doesn't change size and is not movable, we can implement
transactional writing of metadata to the FAT directory entries using this
file as a journal.

Advantages:

- Compatibility with original FAT drivers (without journalling of course)

- Metadata is always consistent (no need for a checkdisk).

Disadvantages:

- Please name them.

I suppose that's how ext3 was done from ext2. Why making the same from FAT
would be a bad idea?

WBR,

Aleksey Bragin.

On Jul 30, 2009, at 1:52 AM, Pierre SCHWEITZER wrote:

Hi,

"I'm still at a loss as to why you are all ignoring the free, open source,
FastFAT driver in the Microsoft WDK.". Wasn't it some kind a license
problem? EULA, or something like that? The question rose when ARM ninjas
imported CDFS driver from the Microsoft WDK. They finally had to remove it.
Anyway, that's not exactly the point.

Regarding your initial question, for FSD an important part is missing in
ReactOS: FsRTL package. Moreover, you may (or, you will?) have problems
using CC package. But, that's a good point in fact. That way, we'll be able
to implement/debug the needed functions, with test case.

Finally, I'd like to come back on that idea: "During the conversation we
also discussed implementing a special journaling extension to FullFAT via
the windows driver.". I've to admit I don't see how it can be a good idea.
IF everything goes well, ReactOS will be able to handle two journalised FS:
NTFS and ext3. Those are known, and used FS. Why should we create a "super"
FAT instead of using those FS? What about compatibilty?
A better idea would to handle exFAT...

Best regards,
P. Schweitzer

  _____  

From: ionucu@videotron.ca
To: ros-dev@reactos.org
Date: Wed, 29 Jul 2009 14:00:08 -0700
Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys

I'm still at a loss as to why you are all ignoring the free, open source,
FastFAT driver in the Microsoft WDK.

On 29-Jul-09, at 10:56 AM, Gabriel ilardi wrote:

Hi James,

Welcome to the team!
ReactOS kernel aims to be compatible with W2k3's, meanwhile Win32 subsystem
aims atm Vista.
You'll come across missing stuff, just search for UNIMPLEMENTED throughout
the code. Encoded started a page with missing functionality
here:http://www.reactos.org/wiki/Missing_ReactOS_Functionality 
Hope you have fun with ReactOS as much as we do...

Gabriel ilardi.