11 May
2005
11 May
'05
8:56 p.m.
Robert Köpferl wrote:
I share the opinion that NFFS is a thing we should
more less avoid.
People are happy if one fs provides reliable access and if it is one
which is also accessible by linux, so what's better? ReactOS users will
potentially avoid MS-NT
Although I think it is of less importance, I can not disagree on this
point more. Most users who will be switching to ReactOS will switching
from windows, not Linux, and so they will be concerned about NTFS
compatibility, not ext. NTFS compatibility will be a desirable feature
for most ReactOS users, but I see it as a nice feature, but not vitally
important. The important reason for using NTFS as I see it, is that I
do not think other filesystems support the needed features.
So coming back to ext?.
There exists a rather good implementation for WinNT:
http://www.fs-driver.org/index.html
better than the italian one. So what's the source of ROS's ext2-IFS in SVN?
Did we already contact the programmer of the mentioned ext2-ifs?
Maybe he is willing to add ACL and owner-support and a Posix-EA <->
IBM-EA mapping to his implementation and work with us?
To my knowledge, ext has no way to store NT security descriptors. You
may be able to write a hack that say, stores all the descriptors in one
file, and then has to search that file for the corresponding descriptor
for every other file on the volume you try to access, but that is an
ugly hack.
Issues:
Owners are 16-bit (since 2.6 also 32-Bit) integers. On NT they are
GUIDs. There is some partitioning in DOMAIN and USER for the GUID.
However noone hinders us to add a flag to our SM to just use 16 or 32-
bit user part for GUIDs to have an easy mapping (also on
Ext2,UFS,Reiser...)
User IDs on NT are SIDs, which are not the same as GUIDs. Technically
SIDs can have variable length, but all MS windows implementations to
date have used a 128 bit length consisting of a domain specific part and
a user specific part. Mapping this structure back and forth to a 32 bit
posix uid is an ugly hack, and as such, is less desirable than native
support. The same goes for trying to map NT ACLs back and forth to
posix chmod bits.
Multiple File streams. NTFS is (looking at the
mentioned table) the only
FS capable of that feature. But what is it? It is just some semantic to
actually hide files having a colon it their name (more less). So such
feature can be easyly simulated by a ROS-IFS. OK, there are issues with
attributes which then exist several times. But this is in my opinion a
minor problem, since no corruption by other OSs can occour (as in FAT).
And be honest. Who uses this feature? MS' AppleTalk-Server AND some
Virus that hides in another stream.
A number of features use data streams including offline files, EFS, on
the fly compressed files, and the summary property sheet that lets users
associate information with files including the author, revision,
description, and search keywords. There is also the file OBJID feature
and reparse points. I am sure there are more things that rely on this
feature that I am forgetting about, and I am also sure that there are
several nice features that we could implement in the future using
streams, so yes, it is something that we want to support.
In the end, you may be able to hack all the features of NTFS into some
other filesystem, but it will take a good amount of dirty tricks and so
won't perform nearly as well. It is better to go with a filesystem that
was designed to handle these features rather than come up with kludgey
ways to force the features into some other filesystem that was not.