"The advantage NTFSDOS Professional has over NTFSDOS is that it relies on Microsoft's implementation of NTFS rather than our own information on the NTFS file-system layout."Mrkaras wrote:Probably not anything you don't all already know about but http://www.sysinternals.com/Utilities/N ... ional.html has a NTFS reader and writer for DOS. they must have suceceded in working out how it works. comercial software, not open source, but perhaps just showing it can be done.
NTFS support thread.
Moderator: Moderator Team
-
- Posts: 4
- Joined: Fri Nov 26, 2004 7:25 pm
Re: Sombody did it
This is a NTFS Chat
Please stick to topic.
There has be more than one filesystem war here we don't need another one inpartical in a important thread.
If you want to suggest other filesystem please look for the open threads or start a new one.
If you have ideas or sources of information to create a ntfs interface for reactos this is the place.
Ie if you created a thread how to create a OpenBFS filesystem driver for Reactos you would not like people saying you should be using Xfs or something else this is exacty the same.(This has happend in the past)
Lets keep these threads clean.
On ntfs. Reactos kernel should be tested against the windows NTFS driver to make sure it works. The read only Linux NTFS driver could be used to aquire the Windows NTFS drive on demard. As I do with insert and captive. Readonly mount the NTFS drive Copy the windows NTFS driver into ram umount the NTFS drive and remount with Captive. Messy but effective.
Combination attack might just do the job. Half Microsoft Half Linux.
The user might not even need to know in most cases it required Microsoft NTFS driver. No Microsoft Driver read only mount until windows driver is provided.
There has be more than one filesystem war here we don't need another one inpartical in a important thread.
If you want to suggest other filesystem please look for the open threads or start a new one.
If you have ideas or sources of information to create a ntfs interface for reactos this is the place.
Ie if you created a thread how to create a OpenBFS filesystem driver for Reactos you would not like people saying you should be using Xfs or something else this is exacty the same.(This has happend in the past)
Lets keep these threads clean.
On ntfs. Reactos kernel should be tested against the windows NTFS driver to make sure it works. The read only Linux NTFS driver could be used to aquire the Windows NTFS drive on demard. As I do with insert and captive. Readonly mount the NTFS drive Copy the windows NTFS driver into ram umount the NTFS drive and remount with Captive. Messy but effective.
Combination attack might just do the job. Half Microsoft Half Linux.
The user might not even need to know in most cases it required Microsoft NTFS driver. No Microsoft Driver read only mount until windows driver is provided.
The logic here is simple.
Why do we need NTFS compatibility?
As a Windows replacement OS, we have to assume that users will have data on NTFS formated volumes that they will need to access. So....
#1 NTFS compatibility is needed. Period.
There are 3 possible ways to implement this in ReactOS.
#A Linux-NTFS
Advantages: Open Source. Can ship with Distro.
Drawbacks: Read Only Solution.
#B Make it possible to use actual Windows NTFS code.
Advantages: Full compatibility with NTFS file system.
Drawbacks: Requires a licensed copy of Windows. Cannot be included with the Distro.
#C Write a compatible NTFS file system from scratch.
Advantages: Open Source, fully compatible.
Drawbacks: Difficult due to lack of documentation. Time consuming.
#2 Problem. None of the solutions completely answers the need for NTFS support in the alloted time frame. The quickest solution is “A”. Read only Access.
We're still presented with the limitations of FAT32 since our NTFS solution hasn't solved the problem.
Solution: An NTFS alternative.
For this we need an open source, fully implemented file system, that supports all the advanced functions of NTFS, even though it is not compatible.
This will become the ReactOS "Native" file format along with FAT, FAT32, and Linux-NTFS read only. There should probably be native support for ISO9660 as well.
What this means is that all these file systems will function with the most minimal installation of ReactOS.
The only thing we need to determine is what Open Source File System supports all the features of NTFS.
If EXT2 works, great.
The problem is that whatever file system is chosen should also work seamlessly with a real Windows machine. At least with a Foreign File system on Windows.
Perhaps a FAT-ROS can be developed easily since NTFS is a descendant of the well documented FAT32. This FAT32 descendant would be an open source cousin of NTFS.
The Development team should assess any candidates for ease of implementation and roll with the easiest one.
Part of the Windows API is Foreign File System Support. Since ReactOS plans to recreate all Windows functionality, it stand to reason that all the other suggested File Systems can be supported eventually, but it is not a priority. Picking ONE format to replace NTFS and having READ access to NTFS is.
Why do we need NTFS compatibility?
As a Windows replacement OS, we have to assume that users will have data on NTFS formated volumes that they will need to access. So....
#1 NTFS compatibility is needed. Period.
There are 3 possible ways to implement this in ReactOS.
#A Linux-NTFS
Advantages: Open Source. Can ship with Distro.
Drawbacks: Read Only Solution.
#B Make it possible to use actual Windows NTFS code.
Advantages: Full compatibility with NTFS file system.
Drawbacks: Requires a licensed copy of Windows. Cannot be included with the Distro.
#C Write a compatible NTFS file system from scratch.
Advantages: Open Source, fully compatible.
Drawbacks: Difficult due to lack of documentation. Time consuming.
#2 Problem. None of the solutions completely answers the need for NTFS support in the alloted time frame. The quickest solution is “A”. Read only Access.
We're still presented with the limitations of FAT32 since our NTFS solution hasn't solved the problem.
Solution: An NTFS alternative.
For this we need an open source, fully implemented file system, that supports all the advanced functions of NTFS, even though it is not compatible.
This will become the ReactOS "Native" file format along with FAT, FAT32, and Linux-NTFS read only. There should probably be native support for ISO9660 as well.
What this means is that all these file systems will function with the most minimal installation of ReactOS.
The only thing we need to determine is what Open Source File System supports all the features of NTFS.
If EXT2 works, great.
The problem is that whatever file system is chosen should also work seamlessly with a real Windows machine. At least with a Foreign File system on Windows.
Perhaps a FAT-ROS can be developed easily since NTFS is a descendant of the well documented FAT32. This FAT32 descendant would be an open source cousin of NTFS.
The Development team should assess any candidates for ease of implementation and roll with the easiest one.
Part of the Windows API is Foreign File System Support. Since ReactOS plans to recreate all Windows functionality, it stand to reason that all the other suggested File Systems can be supported eventually, but it is not a priority. Picking ONE format to replace NTFS and having READ access to NTFS is.
is it possible to create extended permissions or ACLs with other filesystems? maybe we can use an opensource alternative like EXT3 and just have some kind of translation layer or wrapper that will have similar objects associated with the NTFS file system (compression, encryption, quotas, DFS, RXWDOF, etc).
pax mei amici amorque et Iesus sacret omnia
-
- Posts: 31
- Joined: Mon Mar 28, 2005 11:37 pm
Windows Driver Person.
Can windows/reactos handle replacing the current driver with different driver on active filesystem? Make work around alot simpler.
Ie Read only Ntfs driver being swaped with the Micrsoft driver at run time.
Ie the A-B combind solution livecd workable for recovery.
Minor correction on Linux-NTFS allows a verry restricted write system. IE filesize cannot be changed but the data can be changed. Ie loop back filesystem work beos style/Linux style.
Floyd please refer to my post in the development thread http://www.reactos.org/forum/viewtopic.php?t=200 page 2.
someone need to start a thread on how to build the base ntfs compad required to port linux/unix based filesystem matching close to ntfs.
Lets try to get these thread only about ntfs topic. Something might turn up. (Crossing fingers and praying that Microsoft will see common sence and release the specs of ntfs)Hmm do you think we could get the EU to help??? Unfair competion no specs to interface with filesystem. Linux-NTFS would just love it.
We have a current fight in the other thread that is far more developed fight. Ie if we are going to destory a thread with a war might as well be the most harmed allready. Yes I was one who started the other fight. Yes I should know better.
Ie Read only Ntfs driver being swaped with the Micrsoft driver at run time.
Ie the A-B combind solution livecd workable for recovery.
Minor correction on Linux-NTFS allows a verry restricted write system. IE filesize cannot be changed but the data can be changed. Ie loop back filesystem work beos style/Linux style.
Floyd please refer to my post in the development thread http://www.reactos.org/forum/viewtopic.php?t=200 page 2.
someone need to start a thread on how to build the base ntfs compad required to port linux/unix based filesystem matching close to ntfs.
Lets try to get these thread only about ntfs topic. Something might turn up. (Crossing fingers and praying that Microsoft will see common sence and release the specs of ntfs)Hmm do you think we could get the EU to help??? Unfair competion no specs to interface with filesystem. Linux-NTFS would just love it.
We have a current fight in the other thread that is far more developed fight. Ie if we are going to destory a thread with a war might as well be the most harmed allready. Yes I was one who started the other fight. Yes I should know better.
I will ask kindly for this thread to be left for NTFS chat.
http://www.reactos.org/forum/viewtopic.php?t=200 thread is all ready damaged by me all other Filesystem go there for now. 2 destroyed NTFS threads are worth nothing.
Lot of the tech points why ntfs is not going to work soon I placed there too.
But if someone out in the general comes across some information we/I don't know about it would be good if it feeds back. Ie More people read general than support. More eyes more chance of require infomation being found. Floyd I have provided a answer to the permission things as well.
Really Floyd it might be a idea to start a ext3 support thread somewhere and people move to it. Reason support thread is a thread to try to get that filesystem to work.
Lot of the tech points why ntfs is not going to work soon I placed there too.
But if someone out in the general comes across some information we/I don't know about it would be good if it feeds back. Ie More people read general than support. More eyes more chance of require infomation being found. Floyd I have provided a answer to the permission things as well.
Really Floyd it might be a idea to start a ext3 support thread somewhere and people move to it. Reason support thread is a thread to try to get that filesystem to work.
Ratteler: Writing a new NTFS file system from scratch would be an utter waste of time. As you have said, there's already the GPL Linux-NTFS, so why should we start reverse engineering it from scratch?
Just because the current Linux-NTFS is by default read-only, that doesn't meant that's the limit of their goals. Of course they're working on write support, and if you read any documentation at linux-ntfs.sf.net, you'll understand why write support is not as simple as snapping your fingers.
Write support was not the first minor goal, that is true, however read-only support is well when you want to access data, at least; it's better than nothing. Now that read-only support pretty much does every single feature (named data streams, ACLs, etc), now is the time that they are working on truely getting write support working. Not to mention that all the code they write is on their spare time, they are not paid to do it, and neither are they on any scedule of when to code. They do it when the can and feel like it (you try reverse-engineering NTFS for eight years and see if you're still so interested).
Just because the current Linux-NTFS is by default read-only, that doesn't meant that's the limit of their goals. Of course they're working on write support, and if you read any documentation at linux-ntfs.sf.net, you'll understand why write support is not as simple as snapping your fingers.
Write support was not the first minor goal, that is true, however read-only support is well when you want to access data, at least; it's better than nothing. Now that read-only support pretty much does every single feature (named data streams, ACLs, etc), now is the time that they are working on truely getting write support working. Not to mention that all the code they write is on their spare time, they are not paid to do it, and neither are they on any scedule of when to code. They do it when the can and feel like it (you try reverse-engineering NTFS for eight years and see if you're still so interested).
There is already an ext2 driver, and that works with ext3.... If you want to change it to ext3, try yourself cause there are more important things those developers are working on at the moment.Floyd wrote:then let's use ext3 (as it's very very common) and start with that.StringCheesian wrote:Yes. Most Linux filesystems support ACLs. That includes reiserfs and ext3.Floyd wrote:is it possible to create extended permissions or ACLs with other filesystems?
Re: I will ask kindly for this thread to be left for NTFS ch
i read your reply and replied to it there.oiaohm wrote:http://www.reactos.org/forum/viewtopic.php?t=200 thread is all ready damaged by me all other Filesystem go there for now. 2 destroyed NTFS threads are worth nothing.
Lot of the tech points why ntfs is not going to work soon I placed there too.
But if someone out in the general comes across some information we/I don't know about it would be good if it feeds back. Ie More people read general than support. More eyes more chance of require infomation being found. Floyd I have provided a answer to the permission things as well.
Really Floyd it might be a idea to start a ext3 support thread somewhere and people move to it. Reason support thread is a thread to try to get that filesystem to work.
i agree the duplicate threads are getting troublesome.
it appears people don't post to existing threads so much.
pax mei amici amorque et Iesus sacret omnia
*sigh* as already posted on the other threads NTFS is a long term goal and it has been proposed that another filesystem be used in its place. the idea of using another filesystem that has been modified to meet the goals and compatibilty with NTFS is the current discussion. i pulled ext3 out of the air as it is 1) open source as well and 2) an updated version of ext2. before telling me i should "do it myself", please consider that.Phalanx wrote:There is already an ext2 driver, and that works with ext3.... If you want to change it to ext3, try yourself cause there are more important things those developers are working on at the moment.Floyd wrote:then let's use ext3 (as it's very very common) and start with that.StringCheesian wrote: Yes. Most Linux filesystems support ACLs. That includes reiserfs and ext3.
pax mei amici amorque et Iesus sacret omnia
Please consider it has been pulled out of the air hundreds of times already. Even spending the time changing the ext2 to 3 is wasting time that could be used on something else, and it would not really help much at the moment as the kernel is more likly to do the work of damaging the filesystem.Floyd wrote:*sigh* as already posted on the other threads NTFS is a long term goal and it has been proposed that another filesystem be used in its place. the idea of using another filesystem that has been modified to meet the goals and compatibilty with NTFS is the current discussion. i pulled ext3 out of the air as it is 1) open source as well and 2) an updated version of ext2. before telling me i should "do it myself", please consider that.Phalanx wrote:There is already an ext2 driver, and that works with ext3.... If you want to change it to ext3, try yourself cause there are more important things those developers are working on at the moment.Floyd wrote: then let's use ext3 (as it's very very common) and start with that.
Who is online
Users browsing this forum: No registered users and 3 guests