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/barthe 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
