Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As such it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also discussed implementing a special journaling extension to FullFAT via the windows driver.
I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over the coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good contributions to ReactOS in the near future.
James
-- James Walmsley ---------------------------------------- james@worm.me.uk
Hello James, that sounds exciting! Welcome to ReactOS! Hope you willl have fun here :)
On Wed, Jul 29, 2009 at 1:59 PM, James Walmsley james@worm.me.uk wrote:
Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As such it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also discussed implementing a special journaling extension to FullFAT via the windows driver.
I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over the coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good contributions to ReactOS in the near future.
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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.
Date: Wed, 29 Jul 2009 13:59:42 +0200 From: james@worm.me.uk To: ros-dev@reactos.org Subject: [ros-dev] FullFAT replacement for Fastfat.sys
Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As such it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also discussed implementing a special journaling extension to FullFAT via the windows driver.
I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over the coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good contributions to ReactOS in the near future.
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_________________________________________________________________ Accendi le casse, è ora della Messenger Radio! http://www.messenger.it/radioMessenger.aspx
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.
Date: Wed, 29 Jul 2009 13:59:42 +0200 From: james@worm.me.uk To: ros-dev@reactos.org Subject: [ros-dev] FullFAT replacement for Fastfat.sys
Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As
such
it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also
discussed
implementing a special journaling extension to FullFAT via the
windows
driver.
I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over
the
coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good
contributions to
ReactOS in the near future.
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Solo con Messenger, nuovi gadget gratuiti per te. Vieni a scoprirli! _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
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.
Date: Wed, 29 Jul 2009 13:59:42 +0200 From: james@worm.me.uk To: ros-dev@reactos.org Subject: [ros-dev] FullFAT replacement for Fastfat.sys
Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As such it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also discussed implementing a special journaling extension to FullFAT via the windows driver.
I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over the coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good contributions to ReactOS in the near future.
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Solo con Messenger, nuovi gadget gratuiti per te. Vieni a scoprirli! _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards,Alex Ionescu
_________________________________________________________________ Découvrez toutes les possibilités de communication avec vos proches http://www.microsoft.com/windows/windowslive/default.aspx
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.
Date: Wed, 29 Jul 2009 13:59:42 +0200 From: james@worm.me.uk To: ros-dev@reactos.org Subject: [ros-dev] FullFAT replacement for Fastfat.sys
Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As
such
it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also
discussed
implementing a special journaling extension to FullFAT via the
windows
driver.
I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over
the
coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good
contributions to
ReactOS in the near future.
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Solo con Messenger, nuovi gadget gratuiti per te. Vieni a scoprirli! _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Aleksey Bragin 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 mailto:ionucu@videotron.ca To: ros-dev@reactos.org mailto: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. > Date: Wed, 29 Jul 2009 13:59:42 +0200 > From: james@worm.me.uk <mailto:james@worm.me.uk> > To: ros-dev@reactos.org <mailto:ros-dev@reactos.org> > Subject: [ros-dev] FullFAT replacement for Fastfat.sys > > Hi Everyone, > > I just thought I'd introduce myself. I am the author of a new FAT > implementation that was really designed for embedded systems. As such > it provides very good performance. (See www.fullfat-fs.co.uk <http://www.fullfat-fs.co.uk>). > > Fireball contacted me a few days ago to discuss the current > development of FullFAT, and since I have agreed to implement an IFS > driver based on FullFAT with a view to replacing the current > fastfat.sys implementation. During the conversation we also discussed > implementing a special journaling extension to FullFAT via the windows > driver. > > I hope to start work on this project in the next few weeks, and > further to this I would also like to help in some other areas of > ReactOS. I shall be taking a closer look at the ReactOS code over the > coming weeks, and will probably post some questions about various > aspects. I have just bought the Windows Internals, fifth edition > co-authored by Alex Ionescu, hopefully this will provide me with a > good overview of the Windows architecture etc. > > For complete Windows XP compatibility, just how much of the > implementation is currently missing from ReactOS? > > Nice to meet you all, and I hope to provide some good contributions to > ReactOS in the near future. > > James > > -- > James Walmsley > ---------------------------------------- > james@worm.me.uk <mailto:james@worm.me.uk> > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org <mailto:Ros-dev@reactos.org> > http://www.reactos.org/mailman/listinfo/ros-dev ------------------------------------------------------------------------ Solo con Messenger, nuovi gadget gratuiti per te. Vieni a scoprirli! <http://messenger.it/home_gadget.aspx> _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org <mailto:Ros-dev@reactos.org> http://www.reactos.org/mailman/listinfo/ros-devBest regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I like the Idea. Journalling is something I always missed on FAT.
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.
Date: Wed, 29 Jul 2009 13:59:42 +0200 From: james@worm.me.uk To: ros-dev@reactos.org Subject: [ros-dev] FullFAT replacement for Fastfat.sys
Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As such it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also discussed implementing a special journaling extension to FullFAT via the windows driver.
I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over the coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good contributions to ReactOS in the near future.
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Solo con Messenger, nuovi gadget gratuiti per te. Vieni a scoprirli!http://messenger.it/home_gadget.aspx _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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.
Date: Wed, 29 Jul 2009 13:59:42 +0200 From: james@worm.me.uk To: ros-dev@reactos.org Subject: [ros-dev] FullFAT replacement for Fastfat.sys
Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As such it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also discussed implementing a special journaling extension to FullFAT via the windows driver.
I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over the coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good contributions to ReactOS in the near future.
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_____
Solo con Messenger, nuovi gadget gratuiti per te. Vieni a scoprirli! http://messenger.it/home_gadget.aspx _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards,
Alex Ionescu
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
What about long file names? Can't we use something like that to work around the patent?
Ged wrote:
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.
Date: Wed, 29 Jul 2009 13:59:42 +0200 From: james@worm.me.uk To: ros-dev@reactos.org Subject: [ros-dev] FullFAT replacement for Fastfat.sys
Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As such it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also discussed implementing a special journaling extension to FullFAT via the windows driver.
I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over the coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good contributions to ReactOS in the near future.
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Solo con Messenger, nuovi gadget gratuiti per te. Vieni a scoprirli! http://messenger.it/home_gadget.aspx _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards,
Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
2009/7/30 Timo Kreuzer timo.kreuzer@web.de:
What about long file names? Can't we use something like that to work around the patent?
Speaking of the LongFile Name patent and Journaling, there was if I recall, a Linux kernel hacker a while back that addressed both with an interesting patch. If I recall correctly, rather than storing a LFN and a SFN it would only store one or the other and then use the other record as some sort of a checksum on the file in question to achieve a similar effect as a journal record. Maybe its more analogous to UFS soft updates but I think you might get the idea. I'm not all that up on filesystem semantics but I think a bit of googling might turn up what I am talking about.
2009/7/30 Timo Kreuzer timo.kreuzer@web.de:
What about long file names? Can't we use something like that to work around the patent?
Speaking of the LongFile Name patent and Journaling, there was if I recall, a Linux kernel hacker a while back that addressed both with an interesting patch. If I recall correctly, rather than storing a LFN and a SFN it would only store one or the other and then use the other record as some sort of a checksum on the file in question to achieve a similar effect as a journal record. Maybe its more analogous to UFS soft updates but I think you might get the idea. I'm not all that up on filesystem semantics but I think a bit of googling might turn up what I am talking about.
Actually thats just being developed into FullFAT already in preparation for the 1.0.0 release. I believe I already mentioned it, but here's a link the the linux kernel mailing list that explains how the patch works and why its legally valid.
http://lkml.org/lkml/2009/6/26/314 -- A legal discussion about the patch. http://lkml.org/lkml/2009/6/26/313 -- Technical details of what the patch does.
FAT stores a checksum in LFNs of the shortname, this can be used to verify the integrity of LFN entries in a directory. Of course using the linux patch, the short name can be used for other puposes. However its not really journaling because you still have to scan all the directories. This takes a long time.
Sarocet also makes a good point about the problem with a ReactOS journaling file. The journal should store some kind of hash or checksum value of the state of the FAT table (which is probably too big). Or atleast the directories affected by the journal changes. If this hash differs before journal transactions are committed to the FS then the journal should clear that transaction and not commit it.
Really journaling should only be enabled for a ReactOS system partition, using journaling on removable media wouldn't bring any great benefit, because of the effect that Sarocet described.
Still I think the journaling is something we won't add until the driver is working and stable.
James
On Thu, Jul 30, 2009 at 10:53 AM, James Walmsleyjames@worm.me.uk wrote:
Actually thats just being developed into FullFAT already in preparation for the 1.0.0 release. I believe I already mentioned it, but here's a link the the linux kernel mailing list that explains how the patch works and why its legally valid.
http://lkml.org/lkml/2009/6/26/314 -- A legal discussion about the patch. http://lkml.org/lkml/2009/6/26/313 -- Technical details of what the patch does.
FAT stores a checksum in LFNs of the shortname, this can be used to verify the integrity of LFN entries in a directory. Of course using the linux patch, the short name can be used for other puposes. However its not really journaling because you still have to scan all the directories. This takes a long time.
Right. The set of patches I am thinking of is actually older than Tridge's recent patent avoidance work. But I think the concept was the same. If there is a performance hit then it would not worth it.
Sarocet also makes a good point about the problem with a ReactOS journaling file. The journal should store some kind of hash or checksum value of the state of the FAT table (which is probably too big). Or atleast the directories affected by the journal changes. If this hash differs before journal transactions are committed to the FS then the journal should clear that transaction and not commit it.
Really journaling should only be enabled for a ReactOS system partition, using journaling on removable media wouldn't bring any great benefit, because of the effect that Sarocet described.
Still I think the journaling is something we won't add until the driver is working and stable.
I agree. It would be nice to have but that is way down the road but for now, it would just be nice to have a bullet proof fat32 implementation although I suspect a lot of our problems are deeper than the driver itself. If I recall there has been quite a bit of work in the past to get our vfat driver to function on Windows.
Thanks
On Wed, Jul 29, 2009 at 5:00 PM, Alex Ionescuionucu@videotron.ca wrote:
I'm still at a loss as to why you are all ignoring the free, open source, FastFAT driver in the Microsoft WDK.
Speaking just for myself, its not clear to me what in the aggregate of the WDK is actually 'free' and which is just there for reference purposes. I mean it could be perfectly fine and dandy for us to use it, but without the ablity to do proper due diligence, it does not seem to be worth it. Given the history of the fat patent mess, this should seem perfectly clear.
Until Microsoft has the desire to clearly lay out for us what is safe to use in an open source project and what is not, I don't see why its worth the risk.
I didn't say you should copy/paste the driver.
But by all means, using it as a reference and writing an identically functioning driver is 100% legal.
Hence I don't get the point of having "Experts" in FAT come and write an independent driver, or use some other non-Windows driver as reference/source.
In fact, legally, I move that if ReactOS were to strip out 70% of the FastFAT code (totally likely, since the driver is legitimately bloated for things ReactOS doesn't even need to worry about yet), you could add the other 30% *as is*.
I believe this work was already started by one of Aleksey's russian guys, but seems to have been dropped...
On 29-Jul-09, at 4:47 PM, Steven Edwards wrote:
On Wed, Jul 29, 2009 at 5:00 PM, Alex Ionescuionucu@videotron.ca wrote:
I'm still at a loss as to why you are all ignoring the free, open source, FastFAT driver in the Microsoft WDK.
Speaking just for myself, its not clear to me what in the aggregate of the WDK is actually 'free' and which is just there for reference purposes. I mean it could be perfectly fine and dandy for us to use it, but without the ablity to do proper due diligence, it does not seem to be worth it. Given the history of the fat patent mess, this should seem perfectly clear.
Until Microsoft has the desire to clearly lay out for us what is safe to use in an open source project and what is not, I don't see why its worth the risk.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Importing FullFat (even if it requires changes, like converting to kmode) is still WAY faster than developing a new one, based on MS sample code. As we know, FullFat already works, so the testing procedure would be significantly shorter, compared with the one being written from scratch. Finally, FullFat author agreed on colaborating, effectively helping out with the adaptation process. For the new fat driver, we`d still require at least developer, either someone from ReactOS team or outsider. Again, i dont see developers hanging around, waiting to do anything for ReactOS.
So its a choice of ready, funcitoning code and tested, that needs to be adopted, as well as a new developer, eager to help us out. On the other side, there is only a reference MS code, that potentially (even if we`ll be able to actually write a new FAT driver and test it) someone could use as an excuse to question the new driver and spread FUD about its similarity to MS code. We already have seen it... Advangates? I dont see any.
I think that the present need of working, fully featured and stable FAT driver doesn't need any explanation
2009/7/30 Alex Ionescu ionucu@videotron.ca
I didn't say you should copy/paste the driver.
But by all means, using it as a reference and writing an identically functioning driver is 100% legal.
Importing FullFat (even if it requires changes, like converting to kmode) is still WAY faster than developing a new one, based on MS sample code. As we know, FullFat already works, so the testing procedure would be significantly shorter, compared with the one being written from scratch.
FullFAT has already been used by some major embedded projects, Renesas have included it with their own development environment for all their customers.
Similarly a major development framework for Analog Devices Blackfin processors have also adopted FullFAT as a standard part of their library.
FullFAT is well tested already, and I intend to write the driver in a way that fixes to problems can easily be synchronised between the Windows FullFAT driver and the standard general purpose driver.
Finally, FullFat author agreed on colaborating, effectively helping out with the adaptation process. For the new fat driver, we`d still require at least developer, either someone from ReactOS team or outsider. Again, i dont see developers hanging around, waiting to do anything for ReactOS.
In the last year I have gained a substantial interest for Windows internals, particularly kernel mode stuff, and see working with ReactOS as a great opportunity to work with some really smart people, and further my own knowledge and ideas.
So its a choice of ready, funcitoning code and tested, that needs to be adopted, as well as a new developer, eager to help us out. On the other side, there is only a reference MS code, that potentially (even if we`ll be able to actually write a new FAT driver and test it) someone could use as an excuse to question the new driver and spread FUD about its similarity to MS code.
FullFAT will also implement a build-option that removes the FAT patent issues. This is based on the linux patch, for details see:
http://lkml.org/lkml/2009/6/26/313
I think that FullFAT works quite well already, and is 100% my own code from scratch. When ReactOS use this code, then there can be no uncertainty about its legitimacy.
Also addressing the questions regarding a journaling system, we can simply have the driver create a ROS.journal file in the root dir. This file won't mean anything to other systems, and will simply be ignored. Causing no compatibility issues. If another system messes up the FAT table or directory structures thats not the fault of ReactOS, and would require a full chkdsk.
I think the journal stuff would be something we can add once I have FullFAT fully integrated and its working.
Thanks for the input,
James
James Walmsley wrote:
Also addressing the questions regarding a journaling system, we can simply have the driver create a ROS.journal file in the root dir. This file won't mean anything to other systems,
I'd prefer to see it named journal.fat .journal extension would need a LFN. Since this would be a critical file for the fs, we should stick to 8.3 (it's more compatible, allow for more robust code and keeps the gate open for also journaling implementations without long filenames). Journaled fat doesn't need to be reactos specific so a vendor neutral name like journal.fat instead of journal.ros look better.
and will simply be ignored. Causing no compatibility issues. If another system messes up the FAT table or directory structures thats not the fault of ReactOS, and would require a full chkdsk.
For example, the following correct behavior: -ReactOS create a file, allocate and use several blocks and note that at the journal before writing the directory entry. -System hangs. -ReactOS reboots, check the log and free those entries.
Can produce corruption if there's a implementation not aware of journaling in the mix: -ReactOS create a file, allocate and use several blocks and note that at the journal before writing the directory entry. -System hangs. -User reboots in FooOS -FooOS detect the partition incorrectly umounted, chkdsk it and frees those blocks. -FooOS create a new file, using those sectors. This file gets correctly commited. -System hangs again. -User reboot on ReactOS, check the log and free those entries.
Here, by relying on the journal contents, ROS has just corrupted what was a correct FS.
OK, you answered one of my questions regarding journal. But some are still pending: - How to be sure log won't be deleted by user? What if he cleans root dir (in the same time, you'll have deletion of the log file and its modification)? - In case you've a power failure, when you was under ReactOS and making some file operations, log should be then used. But, if you restart using Windows, and dealing with concerned files? It looks a bit like Microsoft NTFS driver and ntfs-3g driver. But, with less securities. With ntfs-3g, in such cases, faulty, the driver don't mount the volume to avoid damaging data, corrupting the volume, etc. Here, as the Microsoft fastfat isn't designed to handle such cases, it could produce really bad effects. Definitely, that mustn't be a priority and must be kept as an improvement when ReactOS will match Windows and will be stable.
Best regards, P. Schweitzer
-------------------------------------------------- From: "James Walmsley" james@worm.me.uk Sent: Thursday, July 30, 2009 1:11 PM To: "ReactOS Development List" ros-dev@reactos.org Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys
Importing FullFat (even if it requires changes, like converting to kmode) is still WAY faster than developing a new one, based on MS sample code. As we know, FullFat already works, so the testing procedure would be significantly shorter, compared with the one being written from scratch.
FullFAT has already been used by some major embedded projects, Renesas have included it with their own development environment for all their customers.
Similarly a major development framework for Analog Devices Blackfin processors have also adopted FullFAT as a standard part of their library.
FullFAT is well tested already, and I intend to write the driver in a way that fixes to problems can easily be synchronised between the Windows FullFAT driver and the standard general purpose driver.
Finally, FullFat author agreed on colaborating, effectively helping out with the adaptation process. For the new fat driver, we`d still require at least developer, either someone from ReactOS team or outsider. Again, i dont see developers hanging around, waiting to do anything for ReactOS.
In the last year I have gained a substantial interest for Windows internals, particularly kernel mode stuff, and see working with ReactOS as a great opportunity to work with some really smart people, and further my own knowledge and ideas.
So its a choice of ready, funcitoning code and tested, that needs to be adopted, as well as a new developer, eager to help us out. On the other side, there is only a reference MS code, that potentially (even if we`ll be able to actually write a new FAT driver and test it) someone could use as an excuse to question the new driver and spread FUD about its similarity to MS code.
FullFAT will also implement a build-option that removes the FAT patent issues. This is based on the linux patch, for details see:
http://lkml.org/lkml/2009/6/26/313
I think that FullFAT works quite well already, and is 100% my own code from scratch. When ReactOS use this code, then there can be no uncertainty about its legitimacy.
Also addressing the questions regarding a journaling system, we can simply have the driver create a ROS.journal file in the root dir. This file won't mean anything to other systems, and will simply be ignored. Causing no compatibility issues. If another system messes up the FAT table or directory structures thats not the fault of ReactOS, and would require a full chkdsk.
I think the journal stuff would be something we can add once I have FullFAT fully integrated and its working.
Thanks for the input,
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
"But, if you restart using Windows, and dealing with concerned files?" This is just the same as if you have installed Linux and Windows in the same PC, and you delete the Linux kernel .img file when running Windows (using http://www.fs-driver.org or whatever). You cant prevent it.
On Thu, Jul 30, 2009 at 5:47 PM, Pierre Schweitzer < pierre.schweitzer@reactos.org> wrote:
OK, you answered one of my questions regarding journal. But some are still pending:
- How to be sure log won't be deleted by user? What if he cleans root dir
(in the same time, you'll have deletion of the log file and its modification)?
- In case you've a power failure, when you was under ReactOS and making
some file operations, log should be then used. But, if you restart using Windows, and dealing with concerned files? It looks a bit like Microsoft NTFS driver and ntfs-3g driver. But, with less securities. With ntfs-3g, in such cases, faulty, the driver don't mount the volume to avoid damaging data, corrupting the volume, etc. Here, as the Microsoft fastfat isn't designed to handle such cases, it could produce really bad effects. Definitely, that mustn't be a priority and must be kept as an improvement when ReactOS will match Windows and will be stable.
Best regards, P. Schweitzer
From: "James Walmsley" james@worm.me.uk Sent: Thursday, July 30, 2009 1:11 PM To: "ReactOS Development List" ros-dev@reactos.org Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys
Importing FullFat (even if it requires changes, like converting to
kmode)
is still WAY faster than developing a new one, based on MS sample code. As we know, FullFat already works, so the testing procedure would be significantly shorter, compared with the one being written from scratch.
FullFAT has already been used by some major embedded projects, Renesas have included it with their own development environment for all their customers.
Similarly a major development framework for Analog Devices Blackfin processors have also adopted FullFAT as a standard part of their library.
FullFAT is well tested already, and I intend to write the driver in a way that fixes to problems can easily be synchronised between the Windows FullFAT driver and the standard general purpose driver.
Finally, FullFat author agreed on colaborating, effectively helping out with the adaptation process. For the new fat driver, we`d still require at least developer, either someone from ReactOS team or outsider. Again, i dont see developers hanging around, waiting to do anything for ReactOS.
In the last year I have gained a substantial interest for Windows internals, particularly kernel mode stuff, and see working with ReactOS as a great opportunity to work with some really smart people, and further my own knowledge and ideas.
So its a choice of ready, funcitoning code and tested, that needs to be adopted, as well as a new developer, eager to help us out. On the other side, there is only a reference MS code, that potentially (even if we`ll be able to actually write a new FAT driver and test it) someone could use
as
an excuse to question the new driver and spread FUD about its similarity to MS code.
FullFAT will also implement a build-option that removes the FAT patent issues. This is based on the linux patch, for details see:
http://lkml.org/lkml/2009/6/26/313
I think that FullFAT works quite well already, and is 100% my own code from scratch. When ReactOS use this code, then there can be no uncertainty about its legitimacy.
Also addressing the questions regarding a journaling system, we can simply have the driver create a ROS.journal file in the root dir. This file won't mean anything to other systems, and will simply be ignored. Causing no compatibility issues. If another system messes up the FAT table or directory structures thats not the fault of ReactOS, and would require a full chkdsk.
I think the journal stuff would be something we can add once I have FullFAT fully integrated and its working.
Thanks for the input,
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
That's a different case. Browsing your Linux partition from Windows isn't that easy, you've to install stuff, etc. Here, we're dealing with something that is supported by ALL OSes. Moreover, your kernel image can be restored. But once you fucked up your files, FS, that isn't so easy...
"But, if you restart using Windows, and dealing with concerned files?" This is just the same as if you have installed Linux and Windows in the same PC, and you delete the Linux kernel .img file when running Windows (using http://www.fs-driver.org or whatever). You cant prevent it.
On Thu, Jul 30, 2009 at 5:47 PM, Pierre Schweitzer < pierre.schweitzer@reactos.org> wrote:
OK, you answered one of my questions regarding journal. But some are still pending:
- How to be sure log won't be deleted by user? What if he cleans root dir
(in the same time, you'll have deletion of the log file and its modification)?
- In case you've a power failure, when you was under ReactOS and making
some file operations, log should be then used. But, if you restart using Windows, and dealing with concerned files? It looks a bit like Microsoft NTFS driver and ntfs-3g driver. But, with less securities. With ntfs-3g, in such cases, faulty, the driver don't mount the volume to avoid damaging data, corrupting the volume, etc. Here, as the Microsoft fastfat isn't designed to handle such cases, it could produce really bad effects. Definitely, that mustn't be a priority and must be kept as an improvement when ReactOS will match Windows and will be stable.
Best regards, P. Schweitzer
From: "James Walmsley" james@worm.me.uk Sent: Thursday, July 30, 2009 1:11 PM To: "ReactOS Development List" ros-dev@reactos.org Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys
Importing FullFat (even if it requires changes, like converting to
kmode)
is still WAY faster than developing a new one, based on MS sample code. As we know, FullFat already works, so the testing procedure would be significantly shorter, compared with the one being written from scratch.
FullFAT has already been used by some major embedded projects, Renesas have included it with their own development environment for all their customers.
Similarly a major development framework for Analog Devices Blackfin processors have also adopted FullFAT as a standard part of their library.
FullFAT is well tested already, and I intend to write the driver in a way that fixes to problems can easily be synchronised between the Windows FullFAT driver and the standard general purpose driver.
Finally, FullFat author agreed on colaborating, effectively helping out with the adaptation process. For the new fat driver, we`d still require at least developer, either someone from ReactOS team or outsider. Again, i dont see developers hanging around, waiting to do anything for ReactOS.
In the last year I have gained a substantial interest for Windows internals, particularly kernel mode stuff, and see working with ReactOS as a great opportunity to work with some really smart people, and further my own knowledge and ideas.
So its a choice of ready, funcitoning code and tested, that needs to be adopted, as well as a new developer, eager to help us out. On the other side, there is only a reference MS code, that potentially (even if we`ll be able to actually write a new FAT driver and test it) someone could use
as
an excuse to question the new driver and spread FUD about its similarity to MS code.
FullFAT will also implement a build-option that removes the FAT patent issues. This is based on the linux patch, for details see:
http://lkml.org/lkml/2009/6/26/313
I think that FullFAT works quite well already, and is 100% my own code from scratch. When ReactOS use this code, then there can be no uncertainty about its legitimacy.
Also addressing the questions regarding a journaling system, we can simply have the driver create a ROS.journal file in the root dir. This file won't mean anything to other systems, and will simply be ignored. Causing no compatibility issues. If another system messes up the FAT table or directory structures thats not the fault of ReactOS, and would require a full chkdsk.
I think the journal stuff would be something we can add once I have FullFAT fully integrated and its working.
Thanks for the input,
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I think you misunderestimate how much work is required to write a kernel mode wrapper around this lib.
It would be much much quicker to use the MS sample code.
I do however prefer to go down the fullfat path than use MS code. I feel uneasy about the legality of using MS code, even if it is supposedly allowed.
Ged.
From: Olaf Siejka [mailto:caemyr@gmail.com] Sent: 30 July 2009 11:52 To: ReactOS Development List Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys
Importing FullFat (even if it requires changes, like converting to kmode) is still WAY faster than developing a new one, based on MS sample code.
Well Aleksey is the one who seems to think that it won't take too long to plug the library into the code he's already written.
On Thu, Jul 30, 2009 at 6:30 AM, Ged gedmurphy@gmail.com wrote:
I think you misunderestimate how much work is required to write a kernel mode wrapper around this lib.
It would be much much quicker to use the MS sample code.
I do however prefer to go down the fullfat path than use MS code. I feel uneasy about the legality of using MS code, even if it is supposedly allowed.
Ged.
*From:* Olaf Siejka [mailto:caemyr@gmail.com] *Sent:* 30 July 2009 11:52 *To:* ReactOS Development List *Subject:* Re: [ros-dev] FullFAT replacement for Fastfat.sys
Importing FullFat (even if it requires changes, like converting to kmode) is still WAY faster than developing a new one, based on MS sample code.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I think that the most important component of fullfat is James Walmsley; Microsoft's fastfat drv misses this feature. :)
'already written' is the key here. There was no mention of that in the original email.
Also, it's still not as easy a task as reworking the MS code, which is effectively what was suggested.
It's going to require a good knowledge of NT FSD's to get everything functioning correctly.
Ged.
From: Zachary Gorden [mailto:drakekaizer666@gmail.com] Sent: 30 July 2009 14:43 To: ReactOS Development List Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys
Well Aleksey is the one who seems to think that it won't take too long to plug the library into the code he's already written.
On Thu, Jul 30, 2009 at 6:30 AM, Ged gedmurphy@gmail.com wrote:
I think you misunderestimate how much work is required to write a kernel mode wrapper around this lib.
It would be much much quicker to use the MS sample code.
I do however prefer to go down the fullfat path than use MS code. I feel uneasy about the legality of using MS code, even if it is supposedly allowed.
Ged.
From: Olaf Siejka [mailto:caemyr@gmail.com] Sent: 30 July 2009 11:52 To: ReactOS Development List Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys
Importing FullFat (even if it requires changes, like converting to kmode) is still WAY faster than developing a new one, based on MS sample code.
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
The NT specific part would be file objects and related operations, IRP handling is partially done already. Actually I stopped at a level which already required initial volume mounting, and traversing the root directory iirc. So it might really be quite fast (development speed wise).
Of course, relying on a reference fastfat from WDK would be also fun and good, Alex is right that probably up to 70% of its source code aren't needed for us, and the other 30% would serve as a good reference. But if there is a way to avoid MS copyrighted code, and there is a great developer who offers his help - FullFAT would be a way to go.
WBR, Aleksey Bragin.
On Jul 30, 2009, at 7:12 PM, Ged wrote:
‘already written’ is the key here. There was no mention of that in the original email.
Also, it’s still not as easy a task as reworking the MS code, which is effectively what was suggested.
It’s going to require a good knowledge of NT FSD’s to get everything functioning correctly.
Ged.
From: Zachary Gorden [mailto:drakekaizer666@gmail.com] Sent: 30 July 2009 14:43 To: ReactOS Development List Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys
Well Aleksey is the one who seems to think that it won't take too long to plug the library into the code he's already written.
On Thu, Jul 30, 2009 at 6:30 AM, Ged gedmurphy@gmail.com wrote:
I think you misunderestimate how much work is required to write a kernel mode wrapper around this lib.
It would be much much quicker to use the MS sample code.
I do however prefer to go down the fullfat path than use MS code. I feel uneasy about the legality of using MS code, even if it is supposedly allowed.
Ged.
From: Olaf Siejka [mailto:caemyr@gmail.com] Sent: 30 July 2009 11:52 To: ReactOS Development List Subject: Re: [ros-dev] FullFAT replacement for Fastfat.sys
Importing FullFat (even if it requires changes, like converting to kmode) is still WAY faster than developing a new one, based on MS sample code.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Fastfat driver works in windows xp... at least in some cases/conditions
On Wed, Jul 29, 2009 at 7:59 AM, James Walmsley james@worm.me.uk wrote:
Hi Everyone,
I just thought I'd introduce myself. I am the author of a new FAT implementation that was really designed for embedded systems. As such it provides very good performance. (See www.fullfat-fs.co.uk).
Fireball contacted me a few days ago to discuss the current development of FullFAT, and since I have agreed to implement an IFS driver based on FullFAT with a view to replacing the current fastfat.sys implementation. During the conversation we also discussed implementing a special journaling extension to FullFAT via the windows driver.
I hope to start work on this project in the next few weeks, and further to this I would also like to help in some other areas of ReactOS. I shall be taking a closer look at the ReactOS code over the coming weeks, and will probably post some questions about various aspects. I have just bought the Windows Internals, fifth edition co-authored by Alex Ionescu, hopefully this will provide me with a good overview of the Windows architecture etc.
For complete Windows XP compatibility, just how much of the implementation is currently missing from ReactOS?
Nice to meet you all, and I hope to provide some good contributions to ReactOS in the near future.
James
-- James Walmsley
james@worm.me.uk
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
In the license file that comes with the WDK, section 2a I, second bullet point.
You may modify, copy, and distribute the source and object code form of code listed in the SAMPLES.TXT file. You may modify, copy, and distribute only the object code form of other sample code that is not listed in the SAMPLES.TXT file.
The fastfat driver is not listed in the SAMPLES.TXT file, so that seems to imply we cannot redistribute the source. Unless you're suggesting we don't care about not being able to distribute code we include with ReactOS?
-
Aleksey Bragin -
Alex Ionescu -
Daniel Reimer -
Dmitry Gorbachev -
Gabriel ilardi -
Ged -
James Walmsley -
Javier Agustìn Fernàndez Arroyo -
Olaf Siejka -
Pierre Schweitzer -
Pierre SCHWEITZER -
Samuel serapion -
Sarocet -
ShadowFlare -
Steven Edwards -
Timo Kreuzer -
Zachary Gorden