FindFirstFile/FindNextFile on SMB shares

[Mike McCormack]

Hi Eric,

I agree with you, the FS implementation is a total mess.

My thoughts for the FS implementation are this:

*  Modify the wineserver interface to pass NT pathnames. Wineserver
    will decide what is a device, a path etc. One possible exception
    is UNC path names. (preliminary patch already posted to wine-patches)

*  In the client side, convert dos path names, device names and any
    other filenames to NT path names. Call NTDLL functions only and let
    NTDLL talk to the server. Kernel32 should contain few or no server
    calls. The server should decide whether the file is a device or a
    normal disk file.
    eg. CreateFile("COM1:") -> NtCreateFile("\Devices\Serial0") -> server
        CreateFile("A:) -> NtCreateFile("\Devices\A:") -> server
        CreateFile("C:\xyz.txt") -> NtCreateFile("\Devices\C:\xyz.txt")

*  Implement "a real driver model" in the client side for dealing with
    ReadFile, WriteFile, delete, rename, SetFilePointer, etc. Probably a
    structure containing function pointers for each operation, which can
    be registered with the client and refered to from wineserver by an
    index.

*  Make directories use real server handles, rather than pointers to
    client structures. NtCreateFile supports taking a directory handle
    and a relative path name from that directory to open files. I've
    tried to keep my SMB implementation seperate from everything else to
    facilitate this.

As you probably know, I've been working on #1 (see my patch from a few 
weeks ago). Dmitry Tmishkov has also been doing some work to unicodify 
the entire file API. His work should be available in two weeks or so.

The blocker for #1 is to convince Alexandre that NT really deals with 
pathes the way my patch does... which involves writing some test 
programs on NT. We need to understand the NtQueryDirectoryFile function 
in more detail to do this.

Mike


Eric Pouech wrote:
...
> I think the FS implementation gets more and more awful
> we need to structure it a bit more (like introducing a real FS driver
> model in Wine, and then implement several drivers DOS, SMB...)
> comments are welcome
> 
> A+