Michael B. Trausch wrote:
NTFS is (and will probably remain) not-so-easy to implement, because it's not terribly well documented. While it might be good to be able to read the filesystems after the system is fully stable and such, it might not be a good idea to attempt to fully implement it.
It may be easier to implement our own filesystem, I'm not sure. At this point I kind of doubt it as I believe the linux ntfs project has documented NTFS nearly completely. I also believe that neither fat nor ext2/3 satisfies our needs with regards to things like EAs, named data streams, and security descriptors.
However, on the other side of that, is this: NTFS is just plain *horrible* if you try to gracefully resize it. Very rarely have I heard of an NTFS-resizing operation come out without some form of data loss or filesystem corruption.
Resize using what utility? Resizing a filesystem is not a function of the filesystem itself, but the software used to rebuild it. The actual NTFS format itself actually lends itself quite well to dynamic resizing. All that is required is to extend/retract the $Bitmap file accordingly. I myself have used Norton Ghost many times to create a system image and later restore that image to several PCs with larger hard drives than the original. Ghost handled resizing the partition flawlessly. Partition Magic on the other hand, I have seen trash hard drives several times.
That having been said, ReactOS can't possibly expect to be able to dual-boot and subsequently replace Windows on a single partition system. It's hard enough to try to convince Linux to boot in a scenerio where 100% of a hard disk is NTFS and a backup, repartition, reformat, restore is not an option.
That is because Linux inherently does not like NTFS. As an NT clone, ReactOS does. Provided that we implement an NTFS driver, installing reactos on an existing windows partition and either dual booting or replacing windows would be quite feasible.
I do think, though, that in the long run, it's safer to just avoid NTFS altogether. It's a huge minefield of messy destruction that could probably wait until after the rest of the system has matured, to be attacked. I'd rather move people away from NTFS and closer to something like ext3 with advanced ACLs. EXT3 at the very least is better then something like NTFS, because it's open, performs decently well, and has support for many different things that NTFS does not. I think it'd be great to have ReactOS have support for it and all of it's features, natively, taking advantage of things like the "executable" attribute that you give a file, instead of the Windows philosophy that everything that's .exe, .cmd, .vbs, .bat, etc., be executable by default.
What features does ext3 support? At the moment I only know of features it does NOT support that NTFS does, and we will need.
Or functionality that when the user (or program on the user's behalf) attempted to execute a file, would check the bit and if it wasn't set, prompt the user if they'd like to have it set. This could easily thwart systems that rely on blindly executing (such as many of the worms and viruses that there are in today's world) from ever seeing the light of day, if the system doesn't execute it by default - similar to the approach used by firewall systems that prohibit applications and other programs from accessing the Internet without first being approved by the user (things like Windows XP SP2's firewall, and ZoneLabs Integrity Client, do this).
Anyway, I'll hop off of my soapbox. :-P
- Mike
That is an application issue really. Specifically web browsers and email clients that blindly ShellExecute() files that come from unknown sources. They usually DO warn the user, but users usually ignore the warning. That is why system administrators should configure the machine to not execute untrusted programs.