RFC: evolution of file management

[Eric Pouech]

Martin Fuchs wrote:
> Hello Eric,
Hi Martin
thanks for the comments
> 
> 
>>the device concept will disappear and be replaced by a "path gate":
>>	in NT-Win32 name space, point where to convert from a
>>	NT-path to a Unix-path
>>
>>	for example, assuming we have created a path-gate from
>>	\\??\c: to /mnt/windows, the NT-path \\??\c:\foo\bar
>>	will be transformed into the unix-path /mnt/windows/foo/bar
> 
> 
> It would be good to implement this "path gates" as near as possible like the way it is implemented in Windows NT/XP. This mapping is done using the NT object namespace. Object namespace is another virtual tree structure similar to a file system or the registry. It is accessed by functions like NtOpenDirectoryObject(), NtOpenSymbolicLinkObject(), NtQueryDirectoryObject(), NtQuerySymbolicLinkObject(), ... There has been a tool in the internet called "winobj.exe", with which you can examine this internal NT object namespace. However it is not compatible to XP, I don't know, if someone has yet updated it. But I do have a own program which can display it also for XP.
> Drive mapping is stored as symbolic links for example at "\GLOBAL??\D:". This links point to the partitions, like e.g. "\Device\HarddiskVolume3". There are also the ArcNames, which you can find in the NT bootloader config file "boot.ini". At "\ArcName\multi(0)disk(0)rdisk(0)" you can find another symbolic link to "\Device\Harddisk0\Partition0".
I do know how it's implemented in NT.
anyway, there are a few differences between ROS and Wine:
- in common, we do need to have the same interface as Windows do. This 
only applies to interface living in user land.
- kernel land is another matter. ROS needs to stick to NT's behavior, 
Wine needs to convert calls to what Unix does provide.
- ROS needs to mount physical drives, Wine makes (it's the current 
implementation, this is open to discussion) part of the Unix file 
hierarchy visible from the windows part

Regarding file support, the minimal things Wine need to do is:
- support the same file naming as NT does (mainly the \??\ part of the 
NT name space), the rest is not absolutely needed. Currently, Wine does 
not implement a unique name space for all the objects (as NT does, using 
sub dir for some differenciation) but rather different name spaces
- to allow the mapping from a NT path to a unix path, there are two 
simple ways to do it:
	=> use all NT name space and somehow inject Unix file name space (/ and 
all the subdirs) in it
	=> store the unix information (the path in the unix / hierarchy) as a 
specific attribute of the NT name space (at least the \??\ subtree)

I chose the second approach (you're more proposing the first one) 
because I felt it was more suited to wine behavior.

Concerning NTDLL's directory objects, I'm still wondering if we need (in 
Wine) to implement them. It's indeed needed in NTDLL's interface (object 
attribute for instance) and implements part of the "path gate" 
(especially some attributes like case sensivity in further lookups...). 
So, this is still part of the open questions I have (I may start without 
directory objects, and add them later on).

One of the strength of current NT name space is the orthogonality which 
is used across all objects in NTDLL (for example, in handle management, 
or sending requests - thru IRPs - at all the objects).
The good side is to be able to convert an operation on a file into an 
IRP which is send to the FS which handles the file, which can in turn 
send it or transform it to another part...
As wine implements a more monolithic approach, and since we don't have 
this orthoganility available today, I'm not yet convinced we need to 
stick more to the NT behavior than what I described above as the minimal 
requirements.

A+

-- 
Eric Pouech