This never made it to the public list... -Gav -- Gavriel State Engineering Architect - Linux Development Corel Corp [EMAIL PROTECTED]
Hello, here at Corel we already have pretty much the same functionality you're discussing here already developed and shipping since Corel Linux 1.0. Here's what we do in brief: - we have a constantly running server process (called netserv) which does a) UNC name resolution and handing b) Credentials (username/domain/password) caching c) Autmounting of shares - we have a shared library (libmwn) which is acting as a wrapper for Linux file I/O. We have our wrappers for open/fopen/access/stat/unlink etc. library functions and system calls. Internally, libmwn looks if a file name is a UNC filename and in such case it issues a "netmap" call to the netserv process. Netserv mounts the corresponding share in the temporary location if necessary (or reuses earlier mounted share if UID of the caller is the same) and returns temporary local path to the libmwn. Libmwn passes that name to the native function/system call and returns to the calling program. When mounting, netserv uses its credentials cache to find out which set of credentials to use. If necessary, user will be prompted for new set of credentials (works OK for us). Netserv monitors successful network access attempts and updates its cache. Additionally, netserv takes care of garbage collection, usage counters, removal of temporary directories, There are plans for adding similar functionality to netserv/libmwn for transparent NFS access. Netserv/libmwn are working great in Corel Linux and can be used by WINE. If WINE is running not in Corel Linux, it is still possible to use all of this, provided netserv is launched by some script or application before all the UNC-related activity begins. (For instance, I have Corel File Manager running in my RedHat-based NetWinder computer and it is using all the abovementioned functionality). Netserv/libmwn are distributed under CPL. Please contact me if you have any questions/concerns. Thanks Oleg Noskov [EMAIL PROTECTED] Gavriel State wrote: > I've cc'd this to the public wine-devel mailing list - this kind of > architectural issue needs to be discussed with everyone. > > Jean-Claude Batista wrote: > > I want to implement the Windows NetBeui functionality within Wine. > > I would appreciate any constructive comments regarding this > > implementation. This is my first idea on how this could be done, > > so if you have the felling that things should be done differently, > > let me know! > > > > The way I see this implementation consists in three levels. The File > > I/O functions, the Windows Networking API ( the WNet functions) > > and the shell functions that deal with virtual folders to implement > > the network neighborhood. > > > > Since a filename can consist of a UNC (Universal Naming Convention) and a > > file path, the file I/O functions must be able to find them on the network. > > I believe the less troublesome way to obtain file network transparency > > would be to use "smbmount" (Samba mount tool) to mount the network drive > > to a temporary path and then use this path to access the file. Once the > > file is no longer needed, we would unmount the path. I'm not sure I could > > call smbd functions directly and using the C code, it might result in a > > licensing conflict between Wine and Samba. Using smbmount might require > > to install it as root with the SUID bit enabled, so that users can mount > > the drives. > > There is a library called 'smbwrapper', that if preloaded before libc, > will replace the libc file management routines with ones that understand > UNC pathnames. IE: You'd be able to fopen "\\server\share\file" directly. > Also, you can list the network neighborhood by just doing an ls on /smb. > There may be a license issue though, in which case we might have to > use smbmount directly as described above. It's probably worth contacting > the Samba team via email if it looks like there's a license issue. > > Note that the Corel File Manager does exactly the same kind of thing (using > smbmount, etc) and they may have already implemented code that might be > useful on the WINE side in some of their libraries. I've cc'd Oleg and Ming > on this message, in case they can give any more insight into this. > > > Since we need to keep track ok all the mounted drives, I think we should > > do that in the Wine server side. Here is how : > > Sounds reasonable. > > > We can have an hash or a list of all the mounted network drives. > > > > struct network_mount > > { > > int count; /* reference count */ > > int hash; /* name hash value */ > > struct network_mount *next; /* hash list */ > > struct network_mount *prev; > > int network_type; /* ex: SAMBA, NFS, etc */ > > char *mount_point; /* name of the temporary mount point */ > > /* ex: "/tmp/.wine_mnt/wmnt0001/" */ > > > > char *network_path; /* ex: "\\HISMACHINE\HISSHARE\" */ > > }; > > > > Two functions get_network_path and release_network_path would be supplied. > > get_network_path would maintain the network path reference count, create > > a temp directory and mount the drive according to the network file system > > (Samba in this case but also NFS in the future). Same thing for > > release_network_drive, it would unmount the drive and erase the subdirectory > > once the reference count reaches zero. > > > > File I/O functions would simply parse the file path to check if it contains > > a UNC, the file would be mounted under the /tmp and the real filename would > > be substituted to file name mounted under the temporary mounted file name. > > The share should be mounted in the user's .wine directory, not in /tmp - > permissions for logon, etc are per-user things. > > Actually, speaking of permissions for log-on, that's something else that > the desktop guys have done: full NT domain login support, and secure password > caching. If you're going to mount a network drive, you need login UI. Is it > safe to bring up UI while we're in the midsts of doing file IO? > > > NOTE: We would know if a file path is a network path because of it's > > MOUNT_PREFIX. ex: "\\HISMACHINE\HISSHARE\sub1\..\subN" will have a mount > > point of /tmp/.wine_mount/wmnt0001. The full name would be > > "/tmp/.wine_mnt/wmnt0001/sub1/../subN" and the MOUNT_PREFIX would be > > "/tmp/.wine_mount/". > > > > NOTE2: "wmnt0001/" is a tempdir name obtained from a GetTempFileName like function. > > Again, other than using '~/.wine/wine_mnt/ instead, this sounds ok - I'm > not sure that a temp name is needed, when we could just concat the server > and share name. IE: > > ~/.wine/wine_mnt/HISMACHINE_HISSHARE/ > > > > > The network path would be unmounted (or its reference count lowered ) when : > > > > 1. a file is closed on file_destroy, if its full file name contains the > > MOUNT_PREFIX. > > 2. before we change the current directory using SetCurrentDirectory, if > > the current directory contains the MOUNT_PREFIX. > > 3. after doing a directory listing (using FindFirstFile, FindNextFile & > > FindClose) from a network path, if the path countains the MOUNT_PREFIX. > > 4. after doing a single directory or file operation like MoveFile, > > CreateDirectory, etc. The network path would be mounted then unmounted. > > > > So everything else will still work as it is. From a performance perspective, > > does this sound reasonable? > > > > The WNet functions would be implemented by spawning smbclients processes > > and capturing the output. The Shell functions that have to be modified/implemented > > still require additional investigation. > > One of the related things we'd have to implement is UI for browsing the Samba network > in the file and printing dialogs... > > > This is still a draft for now but I'm waiting for comments and suggestions! > > > > Thanks, > > > > -- Jean-Claude Batista > > [EMAIL PROTECTED] > > -Gav > > -- > Gavriel State > Engineering Architect - Linux Development > Corel Corp > [EMAIL PROTECTED] -- The free Corel LINUX OS Download is NOW available! Check it out at http://linux.corel.combegin:vcard n:Noskov;Oleg tel;fax:(613) 761-9338 tel;home:(613) 748-9833 tel;work:(613) 728-0826 x1694 x-mozilla-html:TRUE url:http://www.corel.com org:Corel Corp.;Emerging Technologies Group adr:;;1600 Carling Ave.;Ottawa;Ontario;K1Z 8R7;Canada version:2.1 email;internet:[EMAIL PROTECTED] title:Project Leader fn:Oleg Noskov end:vcard
