[borsenkow.msk@sni.de: RE: VFS: samba]

[Miguel de Icaza <miguel nuclecu unam mx>]

For those interested in the VFS, this is currently being discussed as
well on the mc-devel mailing list.

------- Start of forwarded message -------
From: "Andrej Borsenkow" <borsenkow.msk@sni.de>
To: "Timur I. Bakeyev" <timur@comtat.ru>, <mc-devel@nuclecu.unam.mx>,
        "Miguel de Icaza" <miguel@nuclecu.unam.mx>
Cc: <j-grigera@usa.net>
Subject: RE: VFS: samba
Date: Tue, 29 Dec 1998 11:17:19 +0300
Content-Type: text/plain;
	charset="Windows-1252"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800
Importance: Normal
In-Reply-To: <19981229012541.A2163@timur.kazan.su>

>
>     2a. As, SAMBA 2.0 is coming, we can communicate with SAMBA
> team to separate
>     all smbclient functions into lib, and left smbclient as
> simple frontend to
>     the library. And also happily use this library in the MC :)
>

Yep. As mentioned in another mail, please, take a look at smbwrapper. It
already has VFS layer built in and redefines standard system calls such like
open, read, readdir etc. It should be possible to convert it to full fledged
client library. I hope :-)

If anybody is interested - drop a note to mailto:samba-techical@samba.org

And, having smbwrapper makes buitin SMB VFS in Midnight redundant :-)


>     tivity will be the pain. But, still, I think smbclient much
> more preferable va-
>     riant of adding ne FS to MC. (for ex., HTTPFS, another
> candidate for adding,
>     also require extra 200-400Kb for libs, and so on... :)
>

What is needed, is loadable module support. Then, adding new file system
will be a matter of dropping binary in standard place.


/andrej
------- End of forwarded message -------