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 address in the headers is not the poster's real email address. Do not send
private mail to the poster using your mailer's "reply" feature. CC's of mail
to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]".
The poster's email address is "[EMAIL PROTECTED]".
