Why ROS will not work on NTFS/ZFS/Reiser4/whatever right now

[vicmarcal]

exFAT is propietary from Microsoft
http://en.wikipedia.org/wiki/ExFAT

[Ubuntu]

The most important thing is to get ROS to work properly on one file system. Adding more and more things to be included just slows down the project.

Get ROS to work with the absolute basics (fat and a simple appearance) and then concentrate on other file systems and making it look pretty, etc.. That's the smart way to do things! Otherwise the project drags on and on and less and less people take it seriously.

[mitcoes]

We are in 2010 and still in alpha.
Large disks are normal, and BTR FS is coming to Linux.
As BTR FS is open source and FAT or NTFS are bad FS and propierty of MS
remember how many times you must run chkdsk /f
why not make a BTR FS support?
Why is so slow the development of this React OS

I want make a suggestion, ask OS teachers all over the world
to ask their students to make a contribution to ReactOS
solving only 1 thing.

Perhaps this students would make this marvellous project grow a little bit

I'm quitting from MS WOS, I've benn using only ubuntu from 6 months, but I still have a NTFS volume, I'm copying almost archive by archive to my EXT4 disks in order to format and do not lose data.

And NTFS errors do not let me to shrink the partition with Gparted, I'm blaming MS NTFS a lot, but it will be done.

FAT & FAT32 are even worse and also MS patented - remember TOm TOm GO had to change to EXT because of MS FAt patent claims - It would be an excellent idea a MS WOS compatible OS with BTR FS and EXT4 FS fully compatibility, even installing original MS WOS 7.

[disks86]

ReactOS will need NTFS support at some point for compatibility. So once it can support it, NTFS should be used so the driver can get fully tested. My justification for this thought is simply that corruption of an actual windows partition or external NTFS formatted devices like pen drives is not acceptable for a "stable" product. Usage as the default filesystem in testing should provide better coverage in terms of testing. Also using NFTS will allow compatibility with existing Windows recovery & diagnostic tools. So although ReactOS is not to that point should another filesystem be added it should be NTFS IMHO. At any rate we kinda have a cart before the horse problem right now. As far as I know the project still has memory management, unimplemented APIs, and misc bugs to work out before anyones attention can be diverted.

Good thought though I would also like to see ReactOS have as good a selection of filesystems as Linux some day but I don't think it is doable yet with limited resources. On that note with regards to it being 2010 and still in alpha the developers are doing a good job given the limited number of them and legal constraints because they are creating an operating system compatible with an existing one. You have to keep in mind other open source operating systems don't typically have to worry about clean room reverse engineering for compatibility and this team is smaller than some of the other projects out there. Making it work is one thing correctness and compatibility are another animal.

[Z98]

Rather hard to write a driver when the interfaces for the drivers don't exist. So what's the point of having the only person who knows enough about the interfaces to write both drivers and the interfaces themselves work on the drivers when what they won't work until he writes the interfaces? I'd say our priorities are perfectly in line.

With respect to getting students to help, I'm not sure the quality of the work would be much. We don't need people who just come by, do one-offs that may or may not work and may not be designed correctly. Having a few dedicated, competent, and experienced developers is worth far more than having hundreds of people who have no idea what they're doing and are producing gibberish code.

[EmuandCo]

On that note with regards to it being 2010 and still in alpha the developers are doing a good job given the limited number of them and legal constraints because they are creating an operating system compatible with an existing one. You have to keep in mind other open source operating systems don't typically have to worry about clean room reverse engineering for compatibility and this team is smaller than some of the other projects out there. Making it work is one thing correctness and compatibility are another animal.

Read this one closely, mitcoes!

[mitcoes]

Thanks, for the replys, abaut the students, I supose teachers know - It is a hard hipothesis - and only if yhe work WORKS would send it to the project.

There are many small adds that can be done this way as BTR FS support that would be secondary for the actual stage of the development, but would help to arrive faster to the goal.

I quit MS WOS (Microsoft Windows Operating System) and as wine do not support windows drivers and other programs as daemon tools for games, Having future React OS as game system is an interesting way for me and future "Open systems"gamers.

A future dual system installation, with some Linux/haiku/Hurd and a React OS for gaming can be a good choice for full gaming compatibility.

Thanls in advance for your work

[zed260]

ultiamtly i suspect that reactos wont support ntfs till there is a need (how long till the os gets to where it needs 4 gigabyte of space plus to install)much less any applcations you may want to install)


so i suspect that it wont be a major priorty till it starts to limit devlopment


for instance on my windows 7 pc system32 folder in windows folder alone takes up around 2.5 gigabyte so pretty much inevetable that fat32 will be dropped as a filesytem for os before it gets final

[mrugiero]

Thanks, for the replys, abaut the students, I supose teachers know - It is a hard hipothesis - and only if yhe work WORKS would send it to the project.

There are many small adds that can be done this way as BTR FS support that would be secondary for the actual stage of the development, but would help to arrive faster to the goal.

I quit MS WOS (Microsoft Windows Operating System) and as wine do not support windows drivers and other programs as daemon tools for games, Having future React OS as game system is an interesting way for me and future "Open systems"gamers.

A future dual system installation, with some Linux/haiku/Hurd and a React OS for gaming can be a good choice for full gaming compatibility.

Thanls in advance for your work

It's kind of off topic, but you don't need daemon tools to run games on wine.
You can mount the iso with "# mount -o loop "path to iso file" "path where you want to mount it"" and configure wine (you can do so with winecfg) to use as cdrom drive the same folder. It isn't hard to do.
However, every other things you said looks right to me (I may be wrong, too ).

[PurpleGurl]

Speaking of legal constraints, it is more complicated than most think. Actually, NTFS may have less patent encumbrances than FAT32. It seems Microsoft is now enforcing patent issues with FAT32, particularly the LFN part. They don't seem to be going after NTFS users. We might end up needing EXT3 or Reiser4 just to be legal. That would hurt compatibility if those were our only options, but since most software is downloaded or installed from removable media, that wouldn't be the worst scenario.

From what I understand, file systems are supposed to be transparent to the OS, so the layer above the FS is where you get compatibility with Windows in regards to file systems. So software, unless written for a specific FS, won't care. You probably wouldn't get to use a FAT32/NTFS defragmentation program on the others, but if we needed that capability for other formats, then there would be no harm having defraggers specific to Reactos, though that would not be the ideal.

Assuming we stay with FAT32 and don't get threatened with a lawsuit over using it, then one thing I'd like to see is not having the folder handling bug that ALL NT-based versions of Windows have. Since we are writing our own code to get to a very similar point as Windows, we could reasonably write folder handling code without the bug. Because the bug is wide-known, writers of defragmenter programs refuse to sort, move (in a lot of cases), or defragment FAT32 folder entries (but handles NTFS folders well). Defragler, a better defrag utility than a lot out there, will defrag FAT32 folders down to 2 fragments. Others won't touch them at all. I don't think compatibility will be broken if we don't duplicate the bug. The only programs that would realize the bug would be defraggers and disk utilities, and all NT-compatible utilities of this sort are all written to avoid the buggy calls. So even if the behavior is a tad different and is correct rather than "NT compatible," there would be no consequences, since no NT-based FAT32 defraggers use those particular folder management calls. So buggy or fixed, they are not used. But if we have reliable calls to use to defrag FAT32 folders, then we would be free to write Win98 style defragmentation that would be work well under Reactos. As an example of what I mean, consider Norton Utilities. When they still supported 98, that had 2 defraggers, one for 95/98/ME and one for NT/2000/XP. The one for 98 was thorough, sorted folders, defragmented the directory structure, etc. The one for XP didn't sort anything, didn't touch the folders, and left gaps all over the place. The reason for that was the folder bug in the APIs. So here is a case where we can improve things without breaking compatibility.

I have a TB drive I will put in a new system, and my current drive set (RAID 1 array) is 320 GB, and that is divided up in a number of 20-80 GB partitions, and several partitions are NTFS. If I went to Reactos entirely, I could convert those to FAT32 or whatever.

[Haos]

You can mount the iso with "# mount -o loop "path to iso file" "path where you want to mount it"" and configure wine (you can do so with winecfg) to use as cdrom drive the same folder. It isn't hard to do.
However, every other things you said looks right to me (I may be wrong, too ).

ISO yes, but not much more. Daemon Tools can mount a whole range of CD image files

[Mna.]

Will ROS support now FFSDrv?

http://ffsdrv.sourceforge.net/
FFS File System Driver for Windows: enables to read BSD(FreeBSD, NetBSD, OpenBSD) FFS/UFS partitions on Windows 2000/XP/2003.

[Bblaauw]

Will ROS support now FFSDrv?

http://ffsdrv.sourceforge.net/
FFS File System Driver for Windows: enables to read BSD(FreeBSD, NetBSD, OpenBSD) FFS/UFS partitions on Windows 2000/XP/2003.

You'd have to try it. However the website you're linking to mentions read-only abilities, while ReactOS more aims for native filesystems so you can not only read from it, but also write to it and install/boot from it.
For example, ReactOS currently is limited to FAT16/FAT32 for the main part of the operating system. Additionally the bootloader can be installed to FAT12 as well (bootdiskette for example). I think there's an experimental feature somewhere to use Ext2 (as used by Linux). That leaves ext2 and ext3 to be desired as Linux filesystems. Meanwhile it also leaves NTFS and exFAT desired from a Windows point of view.
On the bright side, you can dualboot with DOS on the same partition

[Ercan]

Ext4 is more important than others.