EmuandCo wrote:Err, we never said ntfs will be our primary filesystem. it will be supported for completeness, but right now we go in ext3 direction.
And this is the single most frustrating thing I see frequently coming from ROS development... the primary reason to have an open source NT based OS is native access to *ALL* features of NT file system via Win32 PE executables... anything else I can do from FreeDOS, ntfsDOS and HX-DOS. An Open Source Win32 OS is fun to play with. It's nice. But what I need
is an open source system which links PE files against kernel32.dll, user32.dll and maybe advapi and uses the NT Object Name-Space to access NTFS via native NT objects with their full ACLs, ADSs etc just as the NT kernel handles in memory NT objects and devices... otherwise I may as well stick with a blend of DOS and Wine. Both of which are very stable and slightly limited by their lack of "native support for NTFS".
For me, and probably for many other people, ROS is a toy until it supports NTFS natively. I love the project, but make no mistake about the importance of this "feature". I remember ROS team discussions about whether to support the system Registry using the same file format as Microsoft or whether to just implement it via some existing open source SQL engine... that is not so great an issue, as third party tools can access system.dat and user.dat files for off-line repair. Well listen:-
- NTFS is a must because without it you can't "upgrade" your XP / Vista / se7en install on NTFS to ReactOS without switching FS to ... ext3? Vista and se7en won't install to FAT any-more, because it is too limiting and CANNOT support basic system security. Anything other than NTFS is a no-brainer, you stick with MS.
- You can't mount an MS partition under ROS to use native tools and utilities to repair permissions and other factors via Win32 APIs. If you could (as a system engineer I know fixing someones PC by booting off of a live "distro" to fix their broken PC is a big sell for the "fixee", because my Knoppix rescue disc has sold many home users on the power of GNU, one way or another.
- You can't run many server based applications that rely on NTFS permissions for their own system security without "emulating" those features on top of any other file system... and ReactOS has always been about reimplementing, not emulating. If you want to emulate Windows you use Wine.
Please note, all of the above goes against current ROS dev planning.It is not an official statement of intent
by the ReactOS team, it is completely contrary to the intentions of the ReactOS team
. I am aware of this, and have come to accept it. However, I will not sit silent while you poodle along as you are just so you can "think" that all your supporters are happy with that. I do, and will continue to support your efforts and sing your praises, but it is my opinion
that on this issue you (the active development team doing work I can only dream about being skilled enough to achieve) are following a misguided direction.
EmuandCo wrote:The file system has nothing to do with the OS Design. XP runs on FAT32, too and its still a NT Arch OS.
XP... 2000... NT4 and even NT3 all run certain tasks and applications VERY badly on anything other than NTFS... many native securities introduced in 2000 (in particular) rely heavily on the ACL system implemented in NTFS and XP (SP2, and IE 6 + even on 2K) makes active use of the ADS for internet download warnings... or where you all simply not aware of these "native features"? I think not. I think
you fine fellows are far
too knowledgeable for that. I just can't believe you could have achieved so much without knowing such things.
I'm sure someone
on the active ROS team is aware of them, and has in the back of their mind some idea of how ROS will implement equivalent features, but I never read any mention of it. TBH, I smell a "gotcha". It feels
like the tentacles of MS have put out feelers to say, "You can do this, provided...." and NTFS is in the provisions of ReactOS not getting the big bad MS hammer of lawsuit. But if there are good
answers to all these problems that will be introduced if ReactOS never gets to boot natively off an NTFS partition, please tell us how "ReactOS" believe that overcoming them with some other file system and forcing us to do maintainence on the systems of the corporate sheep with block level systems which may as well be run from DOS or Linux is "better"... please tell us
. Don't just say "we don't want to do it", "it's too hard", "the standard isn't documented"... because most of what you implement in ReactOS is hard, undocumented standards, and implementing sufficient NTFS specific features at API level mapped to an alien filesystem is not going to be easy either.
Z98 wrote:Except we lose all of the security features that depends on the FS. ext3 would not be adequate and NTFS would be a nice endgame. Or something as nice. Considering ext3 is just ext2 with journaling, and ext2 made all sorts of compromises for the sake of speed, etc, etc.
Correct. But "nice" is not strong enough wording IMHO. *IF* full NTFS "emulation" is implemented on ext3FS, or any other FS... say with special hidden files the way a Mac implements it's native resource and data forks on alien filesystems... that is fine for the operation of ROS, and is also a plus for ROS users, *provided* native NTFS support is there in order to maintain compatibility with stubborn and half-well written utilities and server suites which require NTFS at sector level as well as API level... We've seen from Vista how many programs conform to MS API style guidance (which is poor anyway) and still fail to work on an API equivalent upgrade.
clancg2003 wrote:Ok, so if I'm understanding you guys straight, if the developers were to port the NTFS3G implementation from Linux to Windows, then ReactOS would have NTFS that is on the same level as Microsoft's implementation?
NO! You understand wrong... if NTFS3G where implemented natively in ROS it would work as well as the open source communities best current implementation of NTFS... It would work as well as ext3fs on ROS. It would still be a million miles away from being "adequate" for use on anything but a non-Win32/Win64 OS. Running ROS on NTFS via NTFS3G would be as useful as running it on fastFAT, ext2fs, ext3fs, ResizerFS, BFS, FFS etc.
The reason why it is "not up to the job" is because the API it's written against reduces filesystems to Files, Directories and Subdirectories. The bare essentials of *any* filesystem... it's an abstraction of a virtual "thing" which starts from the premiss that "all filesystems are alike" and can and should therefore "be treated equally". The design of FUSE also makes the assumption that "all Operating Systems are basically like Unix", at least to the extent of POSIX compliance, and despite the claims of the quote from Wikipedia above, I have seen no
successful implementation of a host for *any* FUSE filesystem library on the NT architecture which is actually workable in the public domain... for sale, or for open source dissection... (somebody please
give me a link if I'm wrong, because I've seen so many claims and found so little evidence)
wikipedia wrote:It is runnable on Linux, FreeBSD, NetBSD, OpenSolaris, BeOS, QNX, Windows NT, WinCE, Nucleus, VxWorks, Haiku, and Mac OS X.
- Linux = i386 GNU Open Source Unix clone
- FreeBSD = Berkly Institute BSD Open Source Unix clone
- NetBSD = See FreeBSD, it's the same root source with different optimization aims and package management.
- OpenSolaris = Open Sourced former commercial Unix clone
- BeOS = Dead commercial POSIX compliant implementation based on some brilliant re-thinking of the micro-kernel projects.
- QNX = QNX is kUNIX... Quick Unix designed commercially from the ground up to excel at real-time operations.
- Windows NT = I've not seen it, and don't (yet) believe the claim.
- WinCE = I have little to do with this, but I doubt this claim, and would care little if it where true. Windows CE is not much different than Windows ME for mobile devices merged with the multi-platform abilities of NT4 (DEC-Alpha and PPC variants) or an X-Box, if you want to look at it that way.... it's nearly but not quite Windows.
- Nucleus = I know very little of this but the website quotes "Real time kernel, C++ and POSIX interfaces, dynamic download, interprocessor communications."
- VxWorks = I have no idea how this "embedded" OS works, but 2 of the three "host" systems (one of which is required to program it in the first place) are Unix based.
- Haiku = Open Source reimplementation of BeOS. (see above)
- MacOS = It's BSD with a very, very nice GUI and driver system. (specifically, it's Darwin BSD based on the Mach0 kernel)
I'm sure FUSE would run fine under Cygwin
or Services for Unix
layer, that doesn't make it work on native Windows NT.
I watch this subject closely, it is dear to my heart, I have seen all the arguments which generally shut up disbelievers who don't really
understand what non-Windows OS are and are not capable of doing natively, and I still feel like I'm being sold down the river by a politician who doesn't live in the same world I do... the real world I work in (the one most of you work in)... the world where I have to push your product just as hard as the money men, because you are worth it.
I really, really, really want to push ReactOS, but in all honesty I look at my clients and if I'm going to pull them away from the commercial NT kernel OS, even if ROS is not Beta, and everything works flawlessly, the lack of NTFS support is going to be a killer for server devs and admins, for home users who use existing Anti-virus and Anti-Malware systems and Firewalls based on commercial Windows distributions all to the extent that I could sell them on Linux, BSD, Apple or even AROS easier and with a clearer conscience. Leaving only Game players who are happy to get infected every 3rd week and reinstall their OS on that frequency. Especially if ReactOS can be installed "lean and mean" with no superfluous overheads.
That's just not what *I* want to promote ROS for. I want to promote it as Windows that YOU have the source for. That if your server needs to boot in some specific way that requires a tweak to the kernel you can hire a guy to do that for you. That if you want to play games and surf the net in safety you can do it for a whole lot less money that MS ask... and let's be fair, home users don't really get the support from the OS they pay for... they pay for the support given to SMEs and Developers, and that's just not fair. I want to promote it as a free and open source Live! boot CD, DVD or USB stick for maintainence guys, that if they don't need the GDI system running and want to run the NT kernel from a command line with full access to "CACLS" etc and maybe boot GDI at a later date to surf the web they can "build" a boot disc to do that, and it won't take months of trawling through WIM image documentation and BartCD scripting and stuff to achieve it... but I need to promote NTFS, using NTFS features from NT objects in the NT object name-space natively from native Win32/Win64 PE/PE+ programs they can build just the same as they build their existing tools to fix NTFS drives using Windows APIs.
I know games using ADSs for registration information, (they won't install, or can't be registered on FAT partitions) I know tape drive backups which compresses the MFT of your server using a different algorithm to the one used for general data systems... and that compression is embedded in a chip on the tape drive... you can't bypass it, or write a different driver, they're server backup systems for NT servers, the don't work on Linux, the can't be re-written and they can't back-up FAT partitions because "no serious Windows server would run on anything but NTFS" I know "Microsoft Office" uses ADSs to store author, editor lists etc in it's documents. I know Vista keeps much of it's indexed data searches in ADSs, and you can use Google Desktops XML system but if you write a tool to work in co-operation with Vista / Se7en indexing you will need
an ADS implementation. BFS has one, ext3 could fake one, but how is that easier that "getting it right in the first place". ROS is still beta, if it's buggy right now then it's buggy, you'll get bug reports and learn more about NTFS from user responses that anything else.
Try it guys. Try all your applications, from the most common to the most specific, and try copying their files off an NTFS partition and back on to a different NTFS partition under a different boot OS... you will find all sorts of meta-data gets lost... that's normal operation. It's not normal for that information to be lost every time the file is created or saved, and some organisations come to rely on that transaction tracking meta-data. ACLs are used extensively in NT Domains and Workgroups... which is why Microsoft tell you never to place Roaming Profiles on ANYTHING but NTFS... you try putting them on FAT and see (across an SME network) how many more times user profiles have to be re-constructed, especially if your employees are hot-desking. SAMBA fakes this information with SQL (I believe)... but is that really what you want for ReactOS? Again, isn't that pushing us to running Linux and Wine and not ROS? And if you want to take that route... admit, this is a play around project for hobbiests and is never meant to come out of beta. Some other project is going to have to take the most stable version of ReactOS they can get and turn it into a real workable
system... I don't want to advocate that, (it is why BSD looses out to Linux) but I can see you pushing people in that direction on this subject alone.
It's too soon in ROS development to consider production server systems? It's too soon to look at such "rare and uncommon uses of Windows" what? MS Office and IE? That's a rare use? Workgroups and Domains are Rare? And if you aren't already thinking about these implementations of ReactOS then it is too soon for you to be saying "we have no plans of ever
implementing full NTFS support as a native and integral part of ReactOS"... otherwise you need to poll interested parties about why "they would want native NTFS support" and "whether some emulation
of those features and a user-mode basic file access driver" would be sufficient. Because, for me, it is not... I could
be in a minority... but I suspect I am not. I also suspect that many "users" are not aware of how much of their OS doesn't work, fails gracefully or just refuses to run / install if the primary boot partition, or the partition on which they are installed is not flagged as NTFS. Ask them to try it and see the difference.
It's not great, for home users, they just get infected quicker, find the maximum partition size limiting, and get a few less nag screens... but on a DC, or ActiveDirectory setup it is mission critical. Suddenly IIS is more flawed than a Mosaic server with some CGI bolted on, and MS-SQL server is open to all sorts of new and funky vulnerabilities and code stops working for no apparent reason. Roaming profiles become as intermittent as a Rover 523 with a leaky hood on a cold wet day and many decent firewalls just miss too many intrusions or simply refuse to install. Live-backup systems refuse to install, and system up-time becomes minimal (services keep restarting of their own accord). Don't ask them to work on FAT32, try one of the e2fs fsds for everything but the boot partition... the same thing happens. It's NTFS on ReactOS or stick with the commercial implementation for serious power-user to admin work, and there can be no argument in my mind. (None that I've yet heard has convinced me.)
When you say "we aren't going to use NTFS for ReactOS" I read "we aren't a serious project with any real aim to compete with Linux, Windows, MacOS or even AROS or Haiku... we're just having a bit of fun here." and "We don't really care if Windows programs run on ReactOS, just so long as the kernel and driver system is compatible" I am saddened to the bone. What is the point? Are you looking to achieve Windows HAL drivers to power X-Windows on Linux so nVidia and ATI don't have to write custom drivers for those OS? What other practical
use for ReactOS have you got in mind? Who is your target audience for this software? Hackers and geeks who think it's cool to have Windows that Microsoft didn't write and actually works with less software than a MS pre-Alpha OS? Come on... don't sell your self short... Pleeeeeeeeeeeeeeeease.