libsmbclient: Browsing and a URI spec?

Richard Sharpe sharpe at
Wed Jan 3 08:42:09 GMT 2001

At 11:25 AM 1/2/01 -0700, Matt Peterson wrote:
>"Christopher R. Hertel" wrote:

Much trimming has taken place ...

>> On a Windows box, you configure your default workgroup or domain along
>> with your machine name, etc.  It is part of the system configuration.  For
>> applications built on libsmbclient, it is really a user configuration.
>> Perhaps an individual user will want to consistently be within a given
>> workgroup, so the .smbc or .smb.conf file would be read to supply the
>> default.  How that is used is probably an application issue.
>> Could be wrong, though.
>> > Incidentally I'm sure it would be more than reasonable to want to enable
>> > Midnight Commander with smb functionality. I believe it is the foundation
>> > of the default GNOME file manager 'gmc' which IMO is right on the money
>> > as far as the type of applications we've been pondering.
>With regard to the specification of default workgroup, KDE offers
>utility classes (infrastructure) for saving configuration data -- as
>will many other applications.  Thinking out loud... it makes me wonder
>of libsmbclient should rely on a specific file like ~/.smbc.conf or if
>it would be better for developer (via the API) to set the default
>workgroup (on a per process basis).  I suppose that a default value
>could be read from .smbc.conf (if it exists) upon library initialization
>but offer the developer option of changing it.
>I do not think that libsmbclient should mimic windows behavior of making
>default workgroup a system parameter -- especially since it is expected
>that libsmbclient will be used on multi-user (Unix-like) platforms.  At
>the least, it should be a user configurable parameter...  The question I
>contemplate is whether default workgroup needs to be exposed via a
>standard text file at all.  Should it rather be a parameter (provided by
>the developer) to the library initialization API? 
>To a developer default workgroup is not much different than other
>"persistent preference" information like default username (and
>password), etc.  Developers should be free to store persistent
>information in ways that make sense to the application.  In KDE (and
>other file managers), the best way to do this will not be ~/.smbc.conf. 
>libsmbclient should allow developers maximum flexibility to provide very
>integrated applications for their users. libsmbclient should be a
>utility library for developers, not a solution for sysadmins or end
>users (i.e. users should not even know it is there).

While I agree that this is a (long-term) goal, it is going to be tricky!

I have made extensive use of Samba code that is riddled with accesses to
lp_xxx routines that pull values out of the smb.conf file.

The latest changes, which I have yet to commit, make use of a file in
$HOME/.smb/smb.conf and this works reasonably well.

To move in the requested direction, where each application has its own
resources will require a further modification to the smbc_init routine to
perhaps provide a callback that can retrieve parameters. However, I will
have to give serious thought to how this can be integrated into the current
code in such a way that we can continue to build it with Samba and against
the library.

>Neither users nor sysadmins should have to worry about yet another
>configuration file.  Developers *only* should be concerned with the
>details of how to persist preference information. 

Hmmm, adjective not like become verb, me thinks :-)

>Matthew Peterson
>Sr. Software Engineer
>Caldera Systems, Inc
>mpeterson at

Richard Sharpe, sharpe at
Samba (Team member,, Ethereal (Team member,
Contributing author, SAMS Teach Yourself Samba in 24 Hours
Author, Special Edition, Using Samba

More information about the samba-technical mailing list