11 May
2005
11 May
'05
1:24 a.m.
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.