Re: [ros-kernel] File system struct

[KJK::Hyperion <no...@li...>]

At 05.33 30/04/2002, you wrote:
>As for implementing /proc in the posix subsystem vs. the kernel, why 
>should it be implemented in the kernel if it is only going to be seen by 
>the posix subsystem?

because it's a filesystem. Why don't you implement named pipes and 
mailslots in user mode inside kernel32 and csrss? what's the difference?

And I don't want to explain yet another time why /proc and /dev should be 
visible to all subsystems. Let's just say they could all benefit from it. 
Just like they should all benefit from NT security, Windows device 
management (try, just for fun, to read a floppy disk under any Unix - try 
Solaris for added fun), DDI drivers, etc.

>Note that it is currently my opinion that the posix and win32 filesystems 
>are too different to reconcile them ( without unacceptable sacrifices in 
>functionality ), but if you think it can be done, then figure out how to 
>do so, and implement it and/or explain how to the rest of us.  Who knows, 
>maybe you can come up with a way to reconcile them, if so, I'd love to hear it.

I think I already explained this:
  1. introduce a new file information class (FilePosixInformation) for 
attributes common to all Unix filesystems (owner, primary group, access 
bitmask, file type bits). File attributes specific to some filesystems 
(sparse, immutable, append-only, compressed, etc.) will be retrieved and 
set through NtFsControlFile()
  2. Microsoft, amazingly, supports and documents translation between 
Windows SIDs and POSIX uids and gids. Refer to the PSDK for details
  3. while NT ACLs cannot be translated into access masks, the inverse is 
true. We have two cases here:
  3.1. POSIX app accessing Windows filesystem. All required fields, except 
user id, group id and mode, can be retrieved without interpolation. For 
files without an ACL, S_IRWXU | S_IRWXG | S_IRWXO will be returned as 
access mask (that is, the file is freely accessible). Otherwise, the user 
and group id are translated from the owner SID and the primary group SID. 
If the ACL has a structure compatible with access masks, it is translated 
directly, else a null mask can be returned, or a mask can be built 
euristically. When the access mask is changed, the existing ACL on the file 
is dropped and replaced with an ACL that is compatible with the access mask 
(this is the standard behavior on ACL-enabled Unix systems)
  3.2. Windows app accessing Unix filesystem. File attributes are 
translated into the nearest equivalents (file name beginning with dot -> 
hidden, ext2 immutable attribute -> read-only, etc.). Access masks are 
translated into the equivalent ACLs and viceversa. But, if an ACL cannot be 
translated into an access mask, an error is returned. The biggest problem 
is that there's no reliable way to translate from user ids and group ids to 
SIDs. It could be implemented by extending the LSA, but is it worth it? The 
solution is simple: don't use Unix filesystems. Support them for 
compatibility only. And implement special filesystems, like /proc, /dev, 
but also named pipes and mailslots, with NT security semantics
  4. make the ACL editors recognize both standards for ACE order in a DACL: 
POSIX and Win32

>If you are ever on irc, we could discuss this in #ReactOS.

sounds fine. What server?