gvfs and (lib)smbclient (resend)

Ross Lagerwall rosslagerwall at gmail.com
Tue Aug 5 11:51:55 MDT 2014


On Mon, Aug 04, 2014 at 04:38:38PM -0700, Jeremy Allison wrote:
> On Sat, Aug 02, 2014 at 04:45:23PM +0100, Ross Lagerwall wrote:
> > 
> > Well I realise in the open source world you generally don't get what you
> > want without doing the work for it, so I'm probing for ideas and
> > feedback from the community rather than just defining an API that I
> > expect someone to implement.  What I mentioned previously was just the
> > shortcomings of using libsmbclient from gvfs's point-of-view.  Having an
> > API that maps closely to the GIO API [1] would be useful from my point
> > of view but not necessarily to the community at large.  Having an API
> > that abstracts the details of the SMB2 protocol but still exposes most
> > of its functionality could be useful to both parties.
> > 
> > [1] https://developer.gnome.org/gio/stable/GFile.html
> 
> OK, I'm happy to be the point person working
> with you on this.
> 
> First things first - we should get the "enable
> POSIX extensions" code into the tree which will
> allow you (at least over SMB1) to treat Samba
> as a more normal POSIX share (permissions, POSIX
> ACLs etc.).

Does anyone know how OS X makes use of the standard UNIX permissions
with their SMB2 implementation?

> 
> After that we'll start getting creative about
> looking into the SMB2 work, and deciding how
> we can do callbacks for the async stuff gvfs
> wants.

To be honest, it's not a lot of async stuff needed.  The main one is
just a way of transferring data so we can pipeline requests.

> 
> Problem is libsmbclient isn't yet thread-safe
> (although help making it so would be appreciated
> and is probably less hard than we think - most
> things are hung off an isolated context struct
> and we'd just have to add mutexes around the
> thread-unsafe name lookup calls and some other
> places).
> 
> Let's make this happen !
> 

Yes indeed, thanks!  I think that making incremental improvements to
libsmbclient is the best approach going forward.

Regards
-- 
Ross Lagerwall


More information about the samba-technical mailing list