RFC: evolution of file management

[Eric Pouech]

in the process of separating ntdll from kernel32, one of the next hurdle 
if the implementation of NtCreateFile.
Since it's rather a core API, some thoughts are needed. Moreover, there 
are a few shortcomings in current file handling we might want to address.

The goal of this small RFC is to:
1/ gather all known shortcomings of current file implementation
2/ propose some solutions and roadmaps for the implementation

feel free to add your own remarks to these lists.

1/ shortcomings
---------------
1.1) no dynamicity in DOS drive management: user should be able, in 
his/her   session(1), to either change the mapping of a DOS drive 
letter, or mount a SMB share somewhere...)
1.2) mounting should be done session wide and not process wide, and of 
course shared across processes
1.3) ntdll and kernel32 are not separated regarding file management
1.4) devices (vxd and DOS) management is still a hack
1.5) it may be necessary to introduce a notion of filesystem for some 
operations (open, read, write, seek, close, dir_enum, ioctl) in order to 
support several FS (unix, smb...)
1.6) poor management of ejectable devices
1.7) short/long file name conversion should be consistent (across 
several processes in the same session, across several sessions)

Note:
(1) a session is linked to a running instance of the wineserver

2/ proposal
-----------

2.1 "path gates" (target: 1.1, 1.2, 1.3/partly, 1.4/partly, 1.6/partly)

all file names will be handled using the NT-style:
+ DOS paths (C:\foo\bar) into \??\C:\foo\bar
+ network paths (\\station\foo\bar) into \??\UNC\station\foo\bar
+ DOS device names (CON) into \??\CON
+ NT device names (\\.\PhysicalDrive0) into \??\PhysicalDrive0
+ a VXD ?? (normally \\.\VFD) into \??\VFD

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


the path-gate will hold the current options that the device currently 
does (case sensivity, fixed/removable...)

path-gates will be stored in the server (they are session wide)

management of VxD and devices could benefit from it: they could be path 
gates pointing to them selves (or nothing ?)

2.2 FS (target: 1.4/partly, 1.5/partly, 1.6/partly)

I'm still wondering if we really need a FS (even a very simplistic one) 
in Wine

2.3 short/long file names (target 1.7)

since current short file name management seems satisfactory, there's no 
need IMO to move short/long names conversion in the server

-- 
Eric Pouech