NTFS is a dead horse. Basicly if its reactos base Filesystem we are seting self up to be kicked. Fat32 lacks secuirty.
MS Can change the NTFS standard at anytime. Anyone who as installed Windows 2000 and XP in the wrong order. Knows that even MS NTFS drivers can destory filesystems. Ie Windows 2000 first Windows XP secound. Windows XP detects Windows 2000 driver and updates it else all hell breaks loss after a few months.
When reactos filesystem interface is good enough it will be able to use MS NTFS drivers. So not really a big problem.
A base of EXT2 or some other advanced filesystem stops Reactos from being plucked and stuffed by MS changing the NTFS driver.
Order of Importance. EXT2 Posix conversion to Windows permisions, Fat32 since it mostly works now. Then NTFS. Ok hfsplus might even jump NTFS depending on the number of Apple users.
How about ZFS as ReactOS file system?
Moderator: Moderator Team
wine
Wine (darwine) is not a solution for now. Maybe one day. Try to run serious program like arcmap (arcview 9,1) and no chance.
To be a win alternative reactos should give 100% win software compatibility.
So for the topic of zfs, it's a good thing to see it in the future, when compatibility with win will be optain. If you could also look for other format like mac hfs+...
For me I will choosing Darwine or Reactos is't only about compatibility. If Reactos is better, I will go there if Darwine is better I will use it. If any of them could run win program I need, my win2000 copy will do it.
To be a win alternative reactos should give 100% win software compatibility.
So for the topic of zfs, it's a good thing to see it in the future, when compatibility with win will be optain. If you could also look for other format like mac hfs+...
For me I will choosing Darwine or Reactos is't only about compatibility. If Reactos is better, I will go there if Darwine is better I will use it. If any of them could run win program I need, my win2000 copy will do it.
Most likely other filesystems will get look at before version 1.0.0
It just important to get one other filesystem working. Ext2 is the most complete at this time. Focus on it for now. So reactos can use filesystem secuirty and be safe to use.
zfs hfs+ .... The list is endless most likely the most required first after Ext2/3.
Reactos may or may not be more compad than darwine. It all depends on what happens in Wine between now and Reactos being stable. Reactos will have driver interfaces and the means to use Windows Drivers. Some apps need this.
Both Wine and Reactos are going threw a lot of changes.
It just important to get one other filesystem working. Ext2 is the most complete at this time. Focus on it for now. So reactos can use filesystem secuirty and be safe to use.
zfs hfs+ .... The list is endless most likely the most required first after Ext2/3.
Reactos may or may not be more compad than darwine. It all depends on what happens in Wine between now and Reactos being stable. Reactos will have driver interfaces and the means to use Windows Drivers. Some apps need this.
Both Wine and Reactos are going threw a lot of changes.
reiserfs or ext3
Well, my opinion is clearly in favour of an opensource journaling filesystem, either "ext3" or "reiserfs", for long-term solution.
"ext2" can also be considered as a good short- and middle-term solution. It has security, it lacks journaling, it can be used as an interface partition between Windows and Reactos because EXT2 driver exists for Windows though i'm not sure if that driver is write-capable?
"ext2" can also be considered as a good short- and middle-term solution. It has security, it lacks journaling, it can be used as an interface partition between Windows and Reactos because EXT2 driver exists for Windows though i'm not sure if that driver is write-capable?
-
ThePhysicist
- Developer
- Posts: 509
- Joined: Mon Apr 25, 2005 12:46 pm
Re: reiserfs or ext3
ext3 = ext2 + journaling. So you will need an ext2 driver first, then you can add journaling and you have an ext3 driver.steveh wrote:"ext2" can also be considered as a good short- and middle-term solution. It has security, it lacks journaling,
Any filesystem driver for ReactOS will be an interface between Windows and reactOS, because it will (most likely) also run on Windows.steveh wrote:it can be used as an interface partition between Windows and Reactos because EXT2 driver exists for Windows though i'm not sure if that driver is write-capable?
It will be an extremely difficult task to port all Linux IFS drivers to ReactOS. It may happen, but don't count on this kind of support for at least 10 years. NTFS will become ReactOS's primary Filesystem, along with FAT32, because these are the only filesystems Windows supports by default. EXT2 will serve NTFS's purpose until a stable Read/Write NTFS driver is developed or ported.
Really there might be a short cut.
NTFS is not required. Its really not a good idea as a primary filesystem.
NTVFS from samba4 on top of EXT2/3 or any other posix filesystem most of the IFS ones. From a programs point of view the function of NTFS none of the head aches of a new version of Windows destroying Reactos.
This is more achivable than trying to hit the moving target of NTFS.
The operations. Port NTVFS to Reactos. This will be able to attach to Linux filesystem drivers common binding. After than making the Linux filesystem drivers work without needing a kernel. This is more than achivable.
Read/Write NTFS driver in reactos is a direct port of a Linux filesystem driver.
Even when it goes read/write NTFS secuirty will most likely not be funcitoning correctly for a while after that.
NTFS is not required. Its really not a good idea as a primary filesystem.
NTVFS from samba4 on top of EXT2/3 or any other posix filesystem most of the IFS ones. From a programs point of view the function of NTFS none of the head aches of a new version of Windows destroying Reactos.
This is more achivable than trying to hit the moving target of NTFS.
The operations. Port NTVFS to Reactos. This will be able to attach to Linux filesystem drivers common binding. After than making the Linux filesystem drivers work without needing a kernel. This is more than achivable.
Read/Write NTFS driver in reactos is a direct port of a Linux filesystem driver.
Even when it goes read/write NTFS secuirty will most likely not be funcitoning correctly for a while after that.
Read only NTFS driver is all ready in Reactos. The ported Linux NTFS driver.
This driver could be used to aquire the correct driver out a Windows install so you don't damage the filesystem. Note I do this with the linux ntfs when repairing windows installs now access driver load captivefs with the windows NTFS driver and edit disk..
Read/Write NTFS is extreamly trickly to pull off.
Ie a fully operational NTFS driver is not required as long as we have the secuirty and the means to use the MS NTFS driver.
Basicly NTFS is not important at moment the min required function is there.
A filesystem with fully functional secuirty that will not be stuffed up by user error. Ie installing windows and not coping the driver. Or a windows update that updates the NTFS driver then not updating reactos's one. Its a requirement.
Target requirements than worry about nice things. Ie more filesystems fully working NTFS...
This driver could be used to aquire the correct driver out a Windows install so you don't damage the filesystem. Note I do this with the linux ntfs when repairing windows installs now access driver load captivefs with the windows NTFS driver and edit disk..
Read/Write NTFS is extreamly trickly to pull off.
Ie a fully operational NTFS driver is not required as long as we have the secuirty and the means to use the MS NTFS driver.
Basicly NTFS is not important at moment the min required function is there.
A filesystem with fully functional secuirty that will not be stuffed up by user error. Ie installing windows and not coping the driver. Or a windows update that updates the NTFS driver then not updating reactos's one. Its a requirement.
Target requirements than worry about nice things. Ie more filesystems fully working NTFS...
It'd be completely foolish for ROS to support NTFS beyond read-only.
First of all, NTFS isn't a great filesystem. It's decent if you ignore the most glaring flaws such as the fast fragmentation of regularly written files. Hence you'll never want to use NTFS as the FS for a ROS install or associated partitions.
Ergo, the only time when one has an NTFS partition on the same system as a ROS install is when one is dual-booting ROS/Windows (NT/2k/XP/Vista), in which case the (stable) read-only NTFS driver can be used to retrieve the native Windows NTFS driver, as pointed out before.
Fact is that NTFS is a proprietary FS, of which new features can only be painstakingly explored and added to an Open Source driver. NTFS is also one of the weak points of Windows, one upon which the open source community definitely can improve by allowing the user to choose from such excellent FSs as JFS, XFS, ReiserFS, Ext3, etc. such as is done in Linux, the BSDs, etc.
First of all, NTFS isn't a great filesystem. It's decent if you ignore the most glaring flaws such as the fast fragmentation of regularly written files. Hence you'll never want to use NTFS as the FS for a ROS install or associated partitions.
Ergo, the only time when one has an NTFS partition on the same system as a ROS install is when one is dual-booting ROS/Windows (NT/2k/XP/Vista), in which case the (stable) read-only NTFS driver can be used to retrieve the native Windows NTFS driver, as pointed out before.
Fact is that NTFS is a proprietary FS, of which new features can only be painstakingly explored and added to an Open Source driver. NTFS is also one of the weak points of Windows, one upon which the open source community definitely can improve by allowing the user to choose from such excellent FSs as JFS, XFS, ReiserFS, Ext3, etc. such as is done in Linux, the BSDs, etc.
I'm going to disagree with this. While I agree it probably isn't the best file system, there's going to be alot of people switching over from Windows XP (or more likely Vista when this nears 1.0 status). These people are all going to have harddrives formatted in NTFS, that will probably want to keep writing to. It's well known that the Linux-NTFS driver is very close to mature status, so why not include a port of that? It's going to be too unreasonable to tell people that they are going to need to reformat all of their NTFS drives, if they still want to write to them.Elledan wrote:It'd be completely foolish for ROS to support NTFS beyond read-only.
Since ReactOS is targeted to Windows users, the majority of them will have NTFS harddrives. And since the objective is to ease any such transition, then it's somewhat naive to believe that they're willing to sit through a reformating of all their HDs just because ReactOS doesn't have NTFS support. This is especially true of small businesses who have better things to do than constantly work on their IT infrastructure. They're looking for a quick and simple solution.
Even if NTFS isn't the best file system out there, it's what's used by the majority, and sometimes you don't have a choice but to work with it. Also, NTFS is basically part of the Windows NT framework now, or might as well be. ReactOS is targeting the NT framework. Get the basics done, then maybe start worrying about all the other FSs out there.
While the new filesystems like ZFS are interesting, they're more for high demand systems and for tech guys. The average user doesn't care, all they want is something that works. NTFS works for them and switching can be painful for those users, which amounts to them complaining. So let's just avoid that.
Even if NTFS isn't the best file system out there, it's what's used by the majority, and sometimes you don't have a choice but to work with it. Also, NTFS is basically part of the Windows NT framework now, or might as well be. ReactOS is targeting the NT framework. Get the basics done, then maybe start worrying about all the other FSs out there.
While the new filesystems like ZFS are interesting, they're more for high demand systems and for tech guys. The average user doesn't care, all they want is something that works. NTFS works for them and switching can be painful for those users, which amounts to them complaining. So let's just avoid that.
Precisely. NTFS is a moving target, but if a stable driver is developed for, say, NTFS 4.0, a few modifications of that will allow it to read and write to NTFS 5.0, modifications to that allow read/write to NTFS 5.1, WinFS, etc. And another point, a lack of a good NTFS driver could be used against us by MS. They just have to state that ReactOS is "Insufficient for the needs of most users", and tell them that we don't support their filesystems, then, BAM, the mindless majority of the public swallows the bait and starts spreading evil rumors about ReactOS.
Simply put, add NTFS support!
Simply put, add NTFS support!
At some point (perhaps with ReactOS 0.3.0?), ReactOS will be able to use Windows XP's NTFS drivers. Therefore it's simply not necessary to provide NTFS support, because Microsoft does that for us.
You might say that not every one owns a licensed copy of Windows XP, but the people who don't consequently also don't have any NTFS partitions, so they can use ext2/3 or whatever.
Adding NTFS read-write-support for ReactOS would be a pretty pointless waste of developer resources. The people who'd be able to write an NTFS driver probably have skills which could be used more sensibly in other places.
You might say that not every one owns a licensed copy of Windows XP, but the people who don't consequently also don't have any NTFS partitions, so they can use ext2/3 or whatever.
Adding NTFS read-write-support for ReactOS would be a pretty pointless waste of developer resources. The people who'd be able to write an NTFS driver probably have skills which could be used more sensibly in other places.
Who is online
Users browsing this forum: No registered users and 28 guests