NTFS is an important feature of Windows NT, it is one of the most advanced file systems devised. It contains many security devices that makes Windows NT secure. It is much more reliable than FAT.
Perhaps instead of waiting for someone to make complete NTFS support in ReactOS (not that it shouldn't be done), we may make a filesystem of our own that is designed with NTFS features in mind (http://linux-ntfs.sf.net/ntfs/), but since we make it we have complete support for it. I was thinking of the name MUSCLE, a pun of FAT. I'm not exactly sure if the letter mean anything yet, but they could be in the future ;)
On Fri, 25 Mar 2005 14:59, Mike Swanson wrote:
NTFS is an important feature of Windows NT, it is one of the most advanced file systems devised. It contains many security devices that makes Windows NT secure. It is much more reliable than FAT.
That's true enough.
Perhaps instead of waiting for someone to make complete NTFS support in ReactOS (not that it shouldn't be done), we may make a filesystem of our own that is designed with NTFS features in mind (http://linux-ntfs.sf.net/ntfs/), but since we make it we have complete support for it. I was thinking of the name MUSCLE, a pun of FAT. I'm not exactly sure if the letter mean anything yet, but they could be in the future ;)
As long as it's not OBESE (Object Based Enterprise fileSystem (Encryptable) ;)
Wesley Parish
I think there are already enough file systems around. And as one looks some of them provide also very advanced features. I have an eye on an JFS implementation for NT - it's just the usual that I dont find either time or a starting point. The security in NT comes from the object manager and the processes' security tokens which are created by the security authority (which is replacible, see Novel). Thus any FS which allws additional meta info is suitable for us. It's a bad idea to reinvent an own NTFS (and even name it so). Confusion would be great.
Mike Swanson wrote:
NTFS is an important feature of Windows NT, it is one of the most advanced file systems devised. It contains many security devices that makes Windows NT secure. It is much more reliable than FAT.
Perhaps instead of waiting for someone to make complete NTFS support in ReactOS (not that it shouldn't be done), we may make a filesystem of our own that is designed with NTFS features in mind (http://linux-ntfs.sf.net/ntfs/), but since we make it we have complete support for it. I was thinking of the name MUSCLE, a pun of FAT. I'm not exactly sure if the letter mean anything yet, but they could be in the future ;)
I think there are already enough file systems around. And as one looks some of them provide also very advanced features. I have an eye on an JFS implementation for NT - it's just the usual that I dont find either time or a starting point. The security in NT comes from the object manager and the processes' security tokens which are created by the security authority (which is replacible, see Novel). Thus any FS which allws additional meta info is suitable for us. It's a bad idea to reinvent an own NTFS (and even name it so). Confusion would be great.
Mike Swanson wrote:
NTFS is an important feature of Windows NT, it is one of the most advanced file systems devised. It contains many security devices that makes Windows NT secure. It is much more reliable than FAT.
Perhaps instead of waiting for someone to make complete NTFS support in ReactOS (not that it shouldn't be done), we may make a filesystem of our own that is designed with NTFS features in mind (http://linux-ntfs.sf.net/ntfs/), but since we make it we have complete support for it. I was thinking of the name MUSCLE, a pun of FAT. I'm not exactly sure if the letter mean anything yet, but they could be in the future ;)
Just to chime in here... Something I've thought about recently regarding file systems...
I believe there was going to be an ext2 driver in ReactOS. Am I right in thinking that complications arise because of the different ways in which security is implemented for different operating systems? And thus if you use ext2 from Windows or NTFS from Linux, you essentially have unrestricted access to all files (non-encrypted, of course.)
One possible solution might be to provide some sort of GROUPS and PASSWD "emulation" in ReactOS for each user account, so when NTFS is being used, the NT style security descriptors are used, whereas when ext2 is used, the Linux style is used. I'm assuming here of course that Linux uses the group and user IDs for the security info - I could be wrong. Still fairly new to Linux.
The actual emulation implementation wouldn't be too difficult as it'd just be a case of storing the Linux GID and UID for a user - something which should be possible. Maybe the ext2 driver would be responsible for converting the NT security descriptor into a Linux one? Or maybe a common module (linuxids.dll or something?) could perform this conversion.
I'm probably dreaming away here as if it was THAT easy, surely it would have been done already huh?
Robert Köpferl wrote:
I think there are already enough file systems around. And as one looks some of them provide also very advanced features. I have an eye on an JFS implementation for NT - it's just the usual that I dont find either time or a starting point. The security in NT comes from the object manager and the processes' security tokens which are created by the security authority (which is replacible, see Novel). Thus any FS which allws additional meta info is suitable for us. It's a bad idea to reinvent an own NTFS (and even name it so). Confusion would be great.
Mike Swanson wrote:
NTFS is an important feature of Windows NT, it is one of the most advanced file systems devised. It contains many security devices that makes Windows NT secure. It is much more reliable than FAT.
Perhaps instead of waiting for someone to make complete NTFS support in ReactOS (not that it shouldn't be done), we may make a filesystem of our own that is designed with NTFS features in mind (http://linux-ntfs.sf.net/ntfs/), but since we make it we have complete support for it. I was thinking of the name MUSCLE, a pun of FAT. I'm not exactly sure if the letter mean anything yet, but they could be in the future ;)
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
On Wed, 30 Mar 2005 01:46:40 +0100 "Andrew "Silver Blade" Greenwood" lists@silverblade.co.uk wrote:
Just to chime in here... Something I've thought about recently regarding file systems...
I believe there was going to be an ext2 driver in ReactOS. Am I right in thinking that complications arise because of the different ways in which security is implemented for different operating systems?
It's correct to say that the security model wouldn't work on ext2 as it sits, but that isn't why we have troble with it. Our cache manager isn't compatible enough for many filesystems to run at all. Until we fix that security is very low priority from my perspective.
art yerkes wrote:
On Wed, 30 Mar 2005 01:46:40 +0100 "Andrew "Silver Blade" Greenwood" lists@silverblade.co.uk wrote:
Just to chime in here... Something I've thought about recently regarding file systems...
I believe there was going to be an ext2 driver in ReactOS. Am I right in thinking that complications arise because of the different ways in which security is implemented for different operating systems?
It's correct to say that the security model wouldn't work on ext2 as it sits, but that isn't why we have troble with it. Our cache manager isn't compatible enough for many filesystems to run at all. Until we fix that security is very low priority from my perspective.
Ah, I didn't know that was the case. It was just a random thought I had recently, anyhow. Thought I'd share it :)
Since not so long time, also ext3 (2?) supports ACLs. They're (as you tell) however build on different IDs. But this is a problem which also occours between different linux installations. Until you strictly use equal UIDs and GIDs. WinNT/ROS does also just use GIDs/UIDs. They're however GUIDs. Thus a simple workaround would be a flag for the SAM to just use 16-bit IDs or an option to manually specify an ID.
BTW. GUIDs in NTLM are organized as [32Bit-Domaincontrolerspecific][32-Bit User/GroupID with speciall bits]
Andrew "Silver Blade" Greenwood wrote:
Just to chime in here... Something I've thought about recently regarding file systems...
I believe there was going to be an ext2 driver in ReactOS. Am I right in thinking that complications arise because of the different ways in which security is implemented for different operating systems? And thus if you use ext2 from Windows or NTFS from Linux, you essentially have unrestricted access to all files (non-encrypted, of course.)
One possible solution might be to provide some sort of GROUPS and PASSWD "emulation" in ReactOS for each user account, so when NTFS is being used, the NT style security descriptors are used, whereas when ext2 is used, the Linux style is used. I'm assuming here of course that Linux uses the group and user IDs for the security info - I could be wrong. Still fairly new to Linux.
The actual emulation implementation wouldn't be too difficult as it'd just be a case of storing the Linux GID and UID for a user - something which should be possible. Maybe the ext2 driver would be responsible for converting the NT security descriptor into a Linux one? Or maybe a common module (linuxids.dll or something?) could perform this conversion.
I'm probably dreaming away here as if it was THAT easy, surely it would have been done already huh?
My initial thought on this project would be that the filesystem will be built specifically ReactOS' features. ReactOS is also a Windows NT clone, so an NTFS would be most suitable.
Hacking an existing *nix filesystem to work on ReactOS just doesn't seem right, nor does it seem very practical.
I don't see any speciallyty to unix at several of the well known FSs. At least for ext and FFS I'd see a hard affinity towards unix. Look at JFS. It's used by OS/2 as a replacement for HPFS386. It essentially all runs towards owner and ACLs
Mike Swanson wrote:
My initial thought on this project would be that the filesystem will be built specifically ReactOS' features. ReactOS is also a Windows NT clone, so an NTFS would be most suitable.
Hacking an existing *nix filesystem to work on ReactOS just doesn't seem right, nor does it seem very practical.
-
Andrew "Silver Blade" Greenwood -
art yerkes -
Mike Swanson -
Robert Köpferl -
Wesley Parish