25 Mar
2005
25 Mar
'05
2:59 a.m.
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 ;)
--
Mike
25 Mar
25 Mar
8:53 a.m.
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
--
Clinersterton beademung, with all of love - RIP James Blish
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.
28 Mar
28 Mar
9:22 p.m.
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 ;)
29 Mar
29 Mar
10:35 p.m.
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 ;)
30 Mar
30 Mar
12:46 a.m.
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(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev 
2:17 a.m.
On Wed, 30 Mar 2005 01:46:40 +0100
"Andrew \"Silver Blade\" Greenwood" <lists(a)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.
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman
2:19 a.m.
art yerkes wrote:
On Wed, 30 Mar 2005 01:46:40 +0100
"Andrew \"Silver Blade\" Greenwood" <lists(a)silverblade.co.uk>
wrote:
Ah, I didn't know that was the case. It was just a random thought I had
recently, anyhow. Thought I'd share it :)
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.
9:50 p.m.
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?
31 Mar
31 Mar
12:56 a.m.
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.
--
Mike
9:57 p.m.
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.
7208
days inactive
7214
days old
9 comments
5 participants
participants (5)
-
Andrew "Silver Blade" Greenwood -
art yerkes -
Mike Swanson -
Robert Köpferl -
Wesley Parish